Use inheritance instead of annotations for TableExpressionBase (specifically temporal tables)

[roji]

To represent the information needed to implement SQL Server temporal tables, we added annotations to TableExpressionBase. We should instead consider simply extending the appropriate type and adding strongly-typed properties in the standard way, i.e. SqlServerTemporalTableExpression or similar, extending TableExpression.

One advantage of this extensibility story, is that it would allow us to also introduce expressions, visit them, etc. For example, at some point in the distant future, PostgreSQL could extend SelectExpression to have the DISTINCT BY clause, which specifies the columns (expression!) by which DISTINCT should operate.

Note: if we do this, instead of extending TableExpression directly we should have an abstract base class, which forces subclasses to implement the various necessary hooks (Update, SQL quoting for precompilation, etc.). Unfortunately TableExpressionBase is already taken as the hierarchy root - we could consider renaming that to RowSet, at which point we'll have TableExpressionBase as an abstract base class, and a sealed TableExpression for normal tables (SqlServerTemporalTableExpression would extend TableExpressionBase).

Note: the complexity here is that we have general logic for propagating annotations onto owned entity types from their owner. While that general logic may make sense specifically for the temporal annotations (though am not 100% sure why we propagate for owned but not for not-owned relationships), it's certainly not something that should be general for all annotations. For example, if we use an annotation to represent a SQL Server table query hint, does it make sense to always propagate that hint to tables of owned entity types? In any case, we'd need a place in translation where the SQL Server provider would be able to perform the propagation.

/cc @maumar