feat: Support keys and signatures from memory

[SequeI]

Add support for providing elliptic curve keys and signatures as bytes in the library API. Private/public keys can now be passed as bytes (PEM or compressed format), and signatures can be provided as JSON strings or bytes. All changes are backward compatible.

• Signer/Verifier accept keys from bytes or file paths
• Public keys support compressed format (33/49/67 bytes)
• Signature.read() and verify() accept bytes/strings
• Updated documentation and changelog

@makew0rld Please let me know if this is what you had in mind, if anything is missing etc :)

Closes #559

Summary

Checklist

• All commits are signed-off, using DCO
• All new code has docstrings and type annotations
• All new code is covered by tests. Aim for at least 90% coverage. CI is configured to highlight lines not covered by tests.
• Public facing changes are paired with documentation changes
• Release note has been added to CHANGELOG.md if needed

[makew0rld]

Haven't tested, but it looks great thanks! One other related thing that would be nice is the ability to get the signature as bytes/text rather than having to write it to disk.

[SequeI]

One other related thing that would be nice is the ability to get the signature as bytes/text rather than having to write it to disk.

Good idea. Maybe also a --stdout cli bool flag as an alternate to a defined signature path. I think it would do better in a separate PR though as the one has a good amount of API changes as is. Will open an issue to track this! Thanks

Once this is in, I'll push up the second PR

[mihaimaruseac]

Overall, I like the idea of this, but I'm concerned that we hardcode key lengths in several places, rather than being generic.

I'll do a deeper review, but first I wanted to surface the question on whether we can avoid this anti-pattern