Figure out mechanism to evolve the log schema

Gitaly will soon produce a write-ahead log. The repository is replicated by replicating the write-ahead log to the replicas. This brings up some issues around version compatibility that we should have a mechanism to deal with.

• When a new log entry type is introduced, the older nodes may not know how to handle the log entry and thus can't apply it. This creates an issue if new write types are to be supported. This is also a problem in the context of migrations as the older nodes would not necessarily know about the migration.
• When handling is removed for a previous log entry type, the newer nodes will no longer know how to handle it. If a repository is far behind, a newer Gitaly would not know how to apply the log entry. In practice, this is mainly a problem for backups. Applying archived WAL entries on a newer version of Gitaly would no longer work.

We need a policy on when we can drop support for old log entries. We should probably just align this on major version upgrades to go with the existing backwards compatibility guarantees.

We need a controlled way to introduce new log entry types. This should only happen once all nodes are running versions that can process the new log entries. Rolling out a new type will also mean that the older versions can no longer apply the log which makes rollbacks difficult.