Store read no row data

The second half of the remove RowData/RowDef, this time from the read path. The actual fixes for this from the previous commits are very small. The `StoreStorageDescription` had the `expandRow` method, and this switches the read group row to use it. The fallout is more interesting. 

The `StoreStorageDescription#expandRow` needs the `rowtype.Schema` to correctly create the row from the raw data. During the DDL there are two versions of the `rowtype.Schema` in use, so the correct schema is passed down through the operator tree, from `OnlineHelper` during processing. 

The `StoreAdapter` used to keep a reference to the `rowtype.Schema` , but it wasn't updated correctly (especially during DDL processing) and caused test failures. It was removed and code updated to handle that. 

Some of the operators rely upon `rowType == rowType` checks to determine if they are handling rows from one table or another (usually parent or child tables). This make handling the `rowtype.Schema` correctly even more important so the Operators and the `StoreStorageDescription` are using the same schema (hence same rowTypes). This impacts several `it.qp.*IT` tests to pull the rowtype schema from the AIS, not creating a new one. 

In anticipation of removing the `RowDef`, the `TableStatus` is now stored with the `Table`.

The final removal of the `RowData`, `RowDef` and other supporting classes is deferred until the Persistit Storage layer can be removed. The default `FDBStorageDescription` and `FDBStoreDataHelper` also use the RowData binary format for storage. Otherwise all remaining references to `RowData` and `RowDef` or access points have been removed. 

The biggest impact for this was the KeyUpdate IT tests, which relied on pretty precise row readings. Updated these tests to use RowType and Row. There are a lot of simple updates to these tests. 

Converting to the Row and Value storage system uncovered a few hidden bugs: 
- The TBigDecimal self-cast wouldn't work correctly anymore and would return bad results. Now fixed. 
- The VARBINARY self-cast were assuming a fixed size starting, also fixed. 


What do these new arguments mean? Was this just a bad expected?