digest algorithm agility needs refinement

[bc-pi]

As discussed during IETF 115, the approach to hash algorithm agility in -01 is problematic and needs some refinement. Some of the issues that jumped out at me are listed below. But I think that simplifying to just the hashes might be the way to go.

• Where does the HMAC key come from? The salt value that would conceptually/presumably be the HMAC key is part of the string literal value that the digest is computed over, which is awkward. But also not explicitly defined. So it's an exercise left up to the reader, which isn't great for interoperability.
• The JOSE alg registry doesn't seem appropriate for the HMAC algs in this different context. And isn't sufficient (see point above) for interoperability.
• Allowing the value to come from two different unrelated registries or "another specification and/or profile of this specification" without a registry seems problematic on a number of fronts
• The name sd_digest_derivation_alg is longer than typical JWT names (sha 256 could also potentially be a default if the thing isn't present to make things smaller in the common MTI case)
• digest derivation function doesn't seem like a commonly used term
• seems like the alg indicator could/should go under the sd_digests rather than being an independent claim at the same level (unless sd_digests goes away, which I'm starting to think it should based on conversations with Dr. @danielfett on Tues, in which case this point is moot)

[bc-pi]

mostly done with f044eae6bb714e1423056e91940c3a71a548cdb9 and e9cea2ccf1dd164759f9d135797321fc16686768

a bit more tracked with #183