Move Tap14 to deferred with some additional clarification of repository operations

[mnm678]

Requires #158

Please ignore all but the last 3 commits, this is already rebased onto #158 to prevent conflicts. I'll clean up the history here once that is merged.

This pr adds some requested clarification of repository operations, and proposes moving this TAP to accepted based on the PoC in python-tuf.

[JustinCappos]

FYI: the main index of TAPs also needs to be updated to change the status to accepted...

[lukpueh]

Some comments, which I think should be addressed before accepting the TAP

• This PR has conflicts.

• The TAP does not point to a prototype implementation, and the existing prototype implementation (theupdateframework/python-tuf#2114) does not represent the current state of the TAP yet.

• The recently merged PR #158 had a few spelling mistakes and typos in the last commit (e.g. supported-versions with dash instead of underscore)

• The supported_versions.path field seems to be redundant with the convention that spec version X.Y.Z metadata lives in an X directory.

• How does root-filename evolve over root versions? E.g. 2/2.root.json and 2/20.root.json can't both say {"version": 3, "root-filename": "1.root.json", ...}, because 3/1.root.json needs to be signed by "the root key from the most recent metadata [at the time of creating the new root (??)] in the previous major specification version" and keys may have changed between 2/2.root.json and 2/20.root.json.

  Does this mean that root updates need to be synchronized across multiple versions and root-filename needs to be bumped on each root update? IMO that seems necessary for clients, in order to update spec version coming from different root versions. But it also makes the different spec versions less autonomous. Either way I think the TAP should clarify this in the "repository updates" section.

  Besides, how does root-filename evolve for the own and previous versions? E.g. if a repo supports spec versions 2, 3 and 4, what would the supported_versions entries for 2 and 3 likely look like in 3/8.root.json?

• I'd generally like the client update process to be more algorithmic also with regards to the existing client workflow. E.g. @trishankatdatadog suggests that the client should rotate root before looking at supported_versions. Is that the case? The TAP does not make that clear.

[mnm678]

@lukpueh I addressed your text concerns, and will be updating the prototype implementation soon. Hopefully the implementation will further clarify the root update process.

[mnm678]

The implementation now reflects the changes in this TAP. @lukpueh @JustinCappos this is ready for review

[JustinCappos]

I looked and the recent changes are fine with me. (Modulo a minor edit below.)

[JustinCappos]

I approve

[JustinCappos]

Moving to deferred. Lukas and others will add other changes.

[lukpueh]

Suggested change

	The rest of the proposal is implemented as a proof of conceps in [#2114](https://github.com/theupdateframework/python-tuf/pull/2114). The pr can be finalized once this TAP is accepted.
	The rest of the proposal is implemented as a proof of concept in [#2114](https://github.com/theupdateframework/python-tuf/pull/2114). The pr can be finalized once this TAP is accepted.

[lukpueh]

Suggested change

	This field will serve two purpose.
	This field will serve two purposes.