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.

[coveralls]

Pull Request Test Coverage Report for Build 9178137170

Details

• 136 of 139 (97.84%) changed or added relevant lines in 7 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.02%) to 96.637%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/sqlalchemy_declarative_extensions/dialects/postgresql/view.py	60	61	98.36%
src/sqlalchemy_declarative_extensions/view/base.py	63	65	96.92%
<!--	Total:	136	139	97.84%	-->

Totals
Change from base Build 9070561393:	-0.02%
Covered Lines:	2504
Relevant Lines:	2583

---

💛 - Coveralls