Spec doesn't say what happens to locally cached files when root metadata is changed

In theupdateframework/specification#76 I mention that we delete the cached snapshot and timestamp on a verification error to avoid attacks where the attackers sets the file version to MAX_INT. However, we now think that the cached snapshot should be deleted whenever the root info is updated:

If during the normal update process we notice that the root info was updated (because the hash of root.json in the new snapshot is different from the old snapshot) we download new root info and start over, without (yet) downloading a (potential) new index. This means it is important that we not overwrite our local cached snapshot, because if we did we would then on the next iteration conclude there were no updates and we would fail to notice that we should have updated the index. However, unless we do something, this means that we would conclude on the next iteration once again that the root info has changed (because the hash in the new shapshot still doesn't match the hash in the cached snapshot), and we would loop.

Read specification#76 and this issue's cached snapshot and root metadata scenario first. Update the specification to define when cached snapshot and timestamp files are deleted after root metadata changes, and ensure the documented behavior avoids both missed index updates and repeated detection loops.