Replace Factory boilerplate with derive macros

[npajkovsky]

HashFactory hand-wrote an 8-arm match for each of the 10 Hash trait methods plus the string-name lookup in AlgorithmFactory::new, so adding an algorithm meant touching a dozen places. Add a bouncycastle-factory-macros crate providing two derives that generate all of it:

• Hash - the Hash impl, forwarding every method to the
  variant currently held.
• AlgorithmFactory - Default and AlgorithmFactory (new, default_128_bit,
  default_256_bit), driven by a #[factory(name = ...)]
  helper attribute on each variant.

Adding an algorithm is now one variant plus one attribute. hash_factory.rs drops from 254 to 79 lines with no behaviour change; existing tests and doctests cover the generated code.

Each derive is named after the trait it implements - derives live in the macro namespace and traits in the type namespace, so they don't collide (same convention as serde::Serialize).

Also marks HashFactory #[non_exhaustive] so future variants are additive rather than breaking for downstream matches

Fixes: #66

[ounsworth]

I didn't know about the #[non_exhaustive] attribute. That's great. Regardless of whether we macro the factories or not, we should apply that, and I will especially be adding #[non_exhaustive] to all the error type enums.

I particularly like that it doesn't prevent you, inside the crate, from writing exhaustive matches
for example:

        match self {
            Self::SHAKE128(h) => h.hash_xof_out(data, output),
            Self::SHAKE256(h) => h.hash_xof_out(data, output),
        }

which will break and force you to add a new branch if you add a new type to the struct, but any caller outside the library would be required to add the _ = branch if they tried to do the same thing. Brilliant! Thanks for pointing that out.

I created: #79

[npajkovsky]

@jjkurczak @ounsworth I have pushed the KDF factory proc-macro.

[dghgit]

I found this one quite interesting. I think we should just park the factory stuff for now though - where it's going to become important is when we start adding PKIX support, but if the example of bc-java/bc-csharp is anything to go by it's going to be based on the use AlgorithmIdentifier structures and not Strings. So I think the factory approaches, while going on the bench now, will get their day in the Sun, we'll just wait for when we have a clearer picture of what we're feeding into them.