Online DDL metadata processing

Complete flow of metadata for online DDL, including performing `CREATE INDEX` and `ALTER TABLE` in three distinct phases.

This is a large set of changes that consists of two main pieces (described below). It is about the smallest chunk of obviously useful functionality that could be isolated. I'd be happy to break into smaller pieces, that don't do much on their own, if that would be easier for review.

**SchemaManager "online session" interface**:
A handful of new methods are exposed to allow flexible persistence of in-progress changes. These are serialized to a parallel location to the primary AIS and in the same way (i.e. schema granularity). The state is nominally attached to Session, mostly for ease of access, but is truly persistent. This is intended to serve recovery/restarting but is not handled yet. The PSSM changes react to this, along with minor refactoring for common helpers.

One part worth pointing on, perhaps for discussion, is `TableChanges.ChangeSet`. This is a simple set of Protobuf messages that describe a change to the table. It serves the same purpose as the existing `ais.util.TableChange` et al, but is easily serialized. If we aren't opposed to the generated classes being used elsewhere it would be simple to eliminate the siblings.

**BasicDDLFunctions use online session for `createIndexes`, `alterTable`**:
More than half the diff and actually quite noisy. The various alter table methods were already the bulk of this file and they all changed in reaction. Probably easier to look at the new file in isolation.

At a high level, the process is now three phases:
1. Start online session, modify AIS and save change info
2. Reload change sets, perform DDL
3. Move new definition to primary AIS, clear online state

The first and third will be singular (retried) transactions, while the second will ultimately be many smaller ones.

The most important part is that the information for performing the DDL is *entirely* from the persisted changes. This means that every current test that creates indexes or alters is hitting the new code. Additionally, this means that concurrent DML (i.e. next batch of changes for online) has enough information to arrive at the same state.

Otherwise, mostly rearranging or tweaks to work off of `ChangeSet` instead of `ChangedTableDescription`. The primary alter helper, alterTableChangeTable, is now much smaller as the two interesting parts were pulled out into helpers, buildProjectsions and buildRowTypesAndIndexes, to be used by concurrent DML.