Replace HashFactory 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