feat: Begin specialization of postgres view from the base View.

[DanCardin]

Refactors out the notion of dialect-specific view classes that can contain dialect-specific view behaviors. This moves the handling of PGView and PGMaterializedView adapters from alembic_utils to that postgres dialect definition.

Using the @view decorator should work identically before/after this change. However, note this deprecates the use of materialized and constraints through direct construction of a generic View instance. Instead, you should directly construct the dialect-specific variant (of which sqlalchemy_declarative_extensions.dialects.postgresql.View is the only one currently).

The primary addition of this PR is an optional materialized=MaterializedOptions(with_data=False) variant of defining materialized views.

Fixes https://github.com/DanCardin/sqlalchemy-declarative-extensions/issues/60

---

I had considered a MaterializedView variant instead of the MaterializedOptions attribute, but it unsatifactorily messed with typing and the whole comparison system. The marginal UX difference in either direction (imo) is small enough that the much simpler implementation was worth it.