Bug fix: IndexedDoltTable didn't fully implement DoltTable's interface

[fulghum]

IndexedDoltTable wasn't fully compatible with DoltTable's interface, which was causing some queries to execute incorrectly due to using the wrong field indexes. This only happened with queries where the table was used in a read-only context (such as an AS OF query), since in a read-write context WritableIndexedDoltTable is used, which is composed of a WritableDoltTable, so fully inherits the interface. IndexedDoltTable is now consistent with that, and is now composed of a DoltTable instance. This enables the GMS code in assignExecIndexes to use the correct, limited schema of the secondary index and to apply the correct field indexes.

Fixes: #7488

[coffeegoddd]

@fulghum DOLT

comparing_percentages
99.999562 to 99.999562

version	result	total
fd8fcd5	not ok	26
fd8fcd5	ok	5937431

version	total_tests
fd8fcd5	5937457

correctness_percentage
99.999562

[max-hoffman]

LGTM, the source of this bug here is that table pruning does not record certain metadata on the GMS side. We currently expect table sources to be able to tell us both (1) all of the logical columns in the table, and (2) what columns will actually be returned (projected) at execution time. Ideally pruning columns would shift some of this burden for execution indexing into the engine. PrimaryKeySchema is maybe a misleading name for the way this interface is used here. We could have something like LogicalSchema as a subinterface separate from the PkOrdinals() method. As long as there are other places where we depend on PrimaryKeySchema for the logical/execution schema difference, having table sources implement the interface for that info will be good.