refactor: Rework module and feature flag for better v4/v4.2 split

[Bluefinger]

In order to avoid feature flag resolution issues, I've gone and reworked the structure of the project to split the two implementations into separate modules. By default for v0.2 of this crate, going forward the chosen implementation will be Final v4.2, which is meant to be more robust. The legacy final v4 will be behind a feature flag legacy_v4, but enabling that will only expose the module, no longer overriding the implementation output.

To prevent misuse of certain features such as secret generation, I reworked the methods to output structs instead of plain arrays, allowing me to type into the methods that the hashers can only be seeded with the correct secrets type, so you can't use the legacy version to seed the secret of the default hasher.

I'm sure there can be some further deduplication done, but I cba for this part, and probably could be done as a follow-up should there be the need for it.

Closes #10

[Lymia]

I don't see anything obviously wrong with this.

[Bluefinger]

I don't see anything obviously wrong with this.

That's as good enough vote of confidence as I'll take 😄 I'll probably merge this as is after I've done a few more pass-throughs to ensure I haven't missed anything