Preparations for future extension support

[infinisil]

Makes sure that we won't have to break compatibility in the future when extensions are implemented, see #35

• Renames SupportedAttestationStatementFormats to AttestationStatementFormatRegistry
• Introduce the WebAuthnRegistries type, currently only consisting of an AttestationStatementFormatRegistry and use it throughout instead of the latter
• Replace allSupportedFormats :: AttestationStatementFormatRegistry with supportedRegistries :: WebAuthnRegistries
• Make not only the registration response decoding function take a WebAuthnRegistries, but also the authentication response decoding, so that we later don't have to break compatibility when extensions are implemented

[infinisil]

I talked about this with @ErinvanderVeen. We came to this conclusion:

• Don't call these things registries. While they resemble registries to the degree that you register an identifier to a specific format in the server, these are only the supported formats. More formats could be registered but not implemented. So the existing name of SupportedAttestationStatementFormats is good.
• Don't introduce the WebAuthnRegistries type. Breaking compatibility is alright once we start supporting extensions. Also, we have to break compatibility anyways, even with a WebAuthnRegistries type if it gets an additional field (unless we don't export the direct constructors/deconstructors)
• Keep allSupportedFormats
• In order to bring uniformity to decoding, just introduce a decodeCredentialRegistration that doesn't take a SupportedAttestationStatementFormats, while still providing a prime version, decodeCredentialRegistration' which does have the supported formats as an argument. By doing this we allow library users to stay backwards compatible if they use the non-prime version. This later then also works for extensions, at which point we will also introduce a decodeCredentialAuthentication', but keep the decodeCredentialAuthentication with the same type

[infinisil]

Only the last point of the previous comment is remaining to do, which is being done in #138