Change data structure for signatures to use key IDs as dictionary keys

Because signatures (at least in the preferred ed25519 mode) are deterministic products of the key and payload materials, it doesn't seem like there's a use case for more than one signature from the same key ID.

Meanwhile -- and more concerning -- we've now had two implementations that have mistakenly used vulnerable signature threshold checking that could have been avoided by using a more robust data format that intrinsically prevents this attack.

I'm not sure how to make this change in a way that's both clean and backwards-compatible, but I'd even be satisfied getting this change into the hopper for TUF 2.0, even if that's a ways off.

Old:

 "signatures": [
  {
   "keyid": "1bf1c6e3cdd3d3a8420b19199e27511999850f4b376c4547b2f32fba7e80fca3",
   "sig": "90d2a06c7a6c2a6a93a9f5771eb2e5ce0c93dd580bebc2080d10894623cfd6eaed
           f4df84891d5aa37ace3ae3736a698e082e12c300dfe5aee92ea33a8f461f02"
  }...

New:

 "signatures": [
    "1bf1c6e3cdd3d3a8420b19199e27511999850f4b376c4547b2f32fba7e80fca3":
  {
   "sig": "90d2a06c7a6c2a6a93a9f5771eb2e5ce0c93dd580bebc2080d10894623cfd6eaed
           f4df84891d5aa37ace3ae3736a698e082e12c300dfe5aee92ea33a8f461f02"
  }...

I'm assuming there may be future signatures that aren't contained in a single value and therefore can't simply have this structure:

 "signatures": {
    "1bf1c6e3cdd3d3a8420b19199e27511999850f4b376c4547b2f32fba7e80fca3": 
    "90d2a06c7a6c2a6a93a9f5771eb2e5ce0c93dd580bebc2080d10894623cfd6eaed
     f4df84891d5aa37ace3ae3736a698e082e12c300dfe5aee92ea33a8f461f02"
   ...

Start by reviewing the current TUF signature-format specification and the linked issue 154 and GHSA-pwqf-9h7j-7mv8. Compare the existing and proposed representations, then document an agreed TUF 2.0 format and a backwards-compatibility plan; the issue is done when that design is accepted.