Stop reading Npgsql enum type mappings in NpgsqlTypeMappingSource

[roji]

Currently, NpgsqlTypeMappingSource pulls in enum type mappings from the lower-level Npgsql layer; the nice aspects of this is that it's sufficient to configure enums on your NpgsqlDataSource (at the lower-level), and that makes them automatically work with EF too.

Unfortunately that causes some pretty severe issues:

• Since NpgsqlTypeMappingSource is singleton, NpgsqlDataSource must also be a singleton.
  • This is especially problematic since we also optionally resolve NpgsqlDataSource from the application service provider; but since NpgsqlOptionsExtension determines when a new internal service provider is needed, but can't access the application service provider, this is currently causing leaks via EF's service provider caching mechanism #2891.
• It also makes it problematic to call UseNpgsql() with a connection, when that connection comes from a data source; EFCore.PG doesn't see that data source, and therefore doesn't have any enum mappings configured on it. This is the root cause of #3053.

The solution here is simply to have users directly configure enum mappings at the EFCore.PG level; at that point NpgsqlDataSource no longer needs to be a singleton at all, and the mappings will always be there. The disadvantage would be that users need to set up mappings twice - once in EFCore.PG and once in Npgsql.

#2542 would be the mitigation for this, i.e. having EF's UseNpgsql() accept an NpgsqlDataSourceBuilder. This would allow users to continue configure enums once, but at the EF level instead of at the Npgsql level: calling MapEnum() at the EFCore.PG level would automatically also call MapEnum on NpgsqlDataSourceBuilder.

Finally, note the intersection with #1026, which is also about moving enum mappings to be context options, with a convention that propagates them into the model for migrations (removing the need to map twice at that level as well).

/cc @ajcvickers