recovering from Client::update failing to write root metadata

In #304, I'm changing Client::update() to error out if we fail to write metadata to the local FileSystemRepository. Consider:

• The trusted root metadata is version 4.
• We fetch version 5.root.json
• We validate it, and update tuf::Tuf to trust version 5.
• We try to write 5.root.json, but fail because the local device ran out of space.
• Space is cleared.
• We fetch the new timestamp, which was signed by 5.root.json. This is written to local storage.
• We do another update, but because we already trust version 5, we next try to fetch version 6, which doesn't exist.

If we restart the client, we no longer can verify the local timestamp metadata without going online.

Instead, we should consider extending the FileSystemRepository to cache metadata if it encounters an error writing metadata to local storage, and periodically trying to flush the metadata to disk. That will increase the odds that we can recover from this situation.

Start by reading Client::update and FileSystemRepository, then review the related change in #304. Trace how root and timestamp metadata are validated and written, especially after a local write failure. Done means a failed metadata write can be recovered after space is cleared, including across a client restart, without requiring the first update to fetch an unavailable root version.