This modifies keyids in place: The key contents remain the same
* Unfortunately keys get shuffled around since they are sorted by keyid
* The result should be that same HW key will now sign the "new" keyids
* for root, the HW key will sign for both new keyids and old keyid
  (so that both root N and N+1 will reach threshold)

this command can be run on "root" and "targets" (and will fix all keyids
defined in that roles metadata). New versions of the delegated roles
will then be created to make sure they get signed with new keyids.

This makes it possible to sign the same metadata twice:
* currently this is only useful when fixing the keyid compliance issue
  in root (see theupdateframework#292). Basically the user will be asked to sign with
  both the keyid from root N+1 and the keyid from root N.
* there are clear use cases with one signer with multiple keys in
  future (think e.g. key rotation).

Since the import adds custom metadata into existing keys,
keyids become non-compliant. Run force_compliant_keyids() for
imported roles too.

This very annoyingly requires a special case in _sign(): basically
a heuristic that figures that we want to sign with "previous version"
root keys if the keyid of this legacy key can be calculated from
"current version" root key by just removing the custom metadata.