This issue centralizes mapping design decisions for some advanced PostgreSQL types/objects: enums, user-defined ranges

Current situation

• Extensions have to be defined on the model (for migrations).
• Enums (and theoretically composites) need to be mapped to a user CLR type. So they have to be defined once on the model (for migrations) and mapped globally at the ADO level (for ADO and also for NpgsqlTypeMappingSource)
• User-defined ranges don't have a user CLR type (it's always NpgsqlRange<T>). They have to be defined on the model (for migrations) and in the context options (for NpgsqlTypeMappingSource).

Some issues:

• Having to map twice is problematic.
• The default model schema isn't taken into account for enums or user-defined ranges (Mapping issues with schema-scoped enums #930, Enum with a schema, the schema isn't included in CREATE TABLE migration script #1145).
• All ADO global enum mappings must be set up before anything is done with EF Core, since the singleton NpgsqlTypeMappingSource is instantiated and snapshots all the mappings (Multiple database connections cause enumeration type to default to int after first first call #895).
• ADO global enum mappings also mean there are some gotchas when managing multiple databases with different enums etc.

Thoughts

• We should consider having all extension and definitions as context options, like user-defined ranges. This will naturally cause different type mapping sources to be created, isolating the different databases with their different type configurations.
• Things still need to be on the model, because that is the only thing that gets versioned for migrations. We could have a convention that creates the model entries for extensions, ranges and enums on the model based on context options. This would remove the need to double-map.
• ADO mappings are still a problem. We could switch to per-connection mapping in NpgsqlRelationalConnection, based on the context options, but this has some perf consequences (see Speed up connection-specific mapping changes npgsql#2263). Ideally it would still be possible to do global type mapping somehow.