Support Ed25519 in native OTP 23+

[brettbeatty]

Decided to take a crack at #91. I just have the 25519 curve so far, no 448. I thought to not break previous versions there'd just be an OTP-native implementation developers could choose instead of libdecaf/libsodium. But I'm not that experienced with erlang or crypto, so I had some questions:

1. What's the best way to test this? I had thought I'd just copy the tests for :jose_jwa_curve25519, but I haven't been able to run the tests locally (tried docker-build/docker-test and make tests and kept running into snags), so I thought I'd check. In manual testing I just compared the output of these functions to those in :jose_jwa_curve25519.
2. What does the module need to do to not cause problems for OTP versions before 23 (I've only tried it in 24)?

[brettbeatty]

I haven't before worked on projects where authors & such are included in the file. Did I do this section appropriately? I'd just as soon not have my name in here

[potatosalad]

LGTM, this project was originally licensed under MPL 2.0, which was file-based licensing, but it has since been relicensed as MIT.

In either case: I have no idea whether it's appropriate or not, but I included your name anyway 😄

[potatosalad]

@brettbeatty Thank you for this!

I've renamed the files to src/jwa/curve25519/jose_curve25519_crypto.erl and src/jwa/curve448/jose_curve448_crypto.erl.

I also discovered that the Ed25519ph and Ed448ph variants in OTP's crypto are not compatible with IETF RFC 8032 ☹️

However, these variants were never officially supported by JOSE in IETF RFC 8037, so I mostly have them here for backwards compatibility. I modified things so it can fallback to pure-Erlang in those cases if crypto fallback mode is enabled.

I also added a simple check when starting the jose application so it can select one of [libdecaf, libsodium, crypto] depending on which one is best supported by the runtime.