Define upgrade path when tree-head signature format is changed

We have decided to change the serialization of signed data for tree head signatures, implemented in sigsum-go!95 (merged). When this is merged, and log-go is updated to depend on a new version of the sigsum-go library, loading of the server's existing sth file is expected to fail.

There are at least two alternatives for dealing with this upgrade:

1. Document some way to upgrade the file, possibly as a script discarding the old signature and using sigsum-key sign to create a new one (sigsum-key sign probably needs some update to be able to do that), or to be fancy, build two versions of sigsum-key and run the one for verifying the signature and the new one to re-sign.
2. Have the sthFile.Load method (see https://git.glasklar.is/sigsum/core/log-go/-/blob/main/internal/state/sth-file.go#L93) try verifying existing signature using both old and new serialization. Could be done specifically for this method, or transparently in the library.

I think this is the main breakage I see that is serious enough to need a reasonable upgrade path for users. Any early deployments of witnesses or monitors can be upgraded in tandem with the logs they work with (and may need a similar upgrade procedure for their own stored state). An updated sigsum-verify tool will reject proofs that use to be valid, but I think that is acceptable for v0 --> v1 upgrade.