FileMeta verification guidance with client store representations

https://github.com/sigstore/root-signing/pull/376#discussion_r971886294
@kommendorkapten brought up this issue during a change where we used to serve canonicalized repository metadata, and just now switched to normal encoding/json. This technically changes the bytes that are used to calculate the FileMeta checksum and lengths, for example, used in the timestamp.json file for pinning the snapshot.

If clients write metadata to their trusted store in canonicalized form, or in some other representation other than the bytes that were directly received from the repository, then the checksums of their stored metadata no longer match the ones in the trusted FileMeta.

This is particularly important if we have a shared cache that multiple TUF client implementations share: if one writes as canonicalized bytes, and the other in the direct bytes received, then one client will fail depending on the way that the repository wrote the FileMeta.

Should clients ALWAYS write metadata to their trusted store in the exact form that was received from the remote?
Should FileMeta ALWAYS be generated from the canonicalized bytes that were signed?

Start with the linked pull request discussion and the specification's FileMeta and trusted-store guidance. Determine whether the specification should require preserving received bytes, require canonicalized signed bytes, or define another interoperable rule. Done means the representation and checksum behavior are stated unambiguously for clients and shared caches.