Implement TAP-12 for future-proofing

[znewman01]

With the python-tuf implementation, I think that we can move TAP 12 to accepted pretty quickly. Unless there are strong objections to the TAP that will lead to major changes (which I haven't seen), I'd argue for future-proofing go-tuf by implementing TAP 12 now. It may make the implementation temporarily out of sync with the specification, but not in a major way, and not in a way that affects security (as described in more detail in the TAP).

Originally posted by @mnm678 in #228 (comment)

@mnm678: I think I agree with you, but I want to clarify what that would mean:

• We can just keep producing keyIDs using SHA2, no change needed there
• We need to double-check that we don't add multiple distinct keys with the same keyID (this is done, but we should allow adding multiple identical keys to prevent errors)
• Make sure keys are managed locally to each metadata file, not globally (I think this is the case but need to double-check)
• During signature verification, need to enforce the uniqueness of each key

[mnm678]

This looks like a good checklist. We may eventually want to add a couple of sanity checks in case a user adds a keyid not using SHA2. Generally the delegating user is trusted to set the mappings, but it'd be nice to have some kind of warning if they accidentally add the same key with a different keyid.