Rework comparisons to use pg_settings data

[rustprooflabs]

Should address #3 and #7.

Reworking how configuration data is parsed with data from pg_catalog.pg_settings instead of the postgresql.conf data. This greatly simplifies the process of setting up a new Postgres major version, and allows new checks on data types for each configuration.

With this change will likely come the removal of the "compare your config" option. The better way for users to do this will be to use a SQL query to compare their bool_val and setting directly in their database, remove the need to look at the config file at all.

[rustprooflabs]

Before and after screenshots below! I think this change is well worth the effort for these improvements.

Version 14 -> 16 display

The current display is has basic value checking, with poor NaN handling, and limited details. New, removed, and updated are lumped into a single table. This output relied on a lot of manual setup prone to human error.

The new version splits new/removed/updated into three sections and tables, showing an increased number of relevant details for each group. The new tables all include the GUC's category and short description providing more context.

The top section shows changes to existing parameters. The "changed" column explains the change type and old/new values.

Update detection now considers vartype addressing #7. The following screenshot shows the notice that the wal_compression guc changed from bool to enum.

The new and removed sections show the same basic columns including default value, variable type and enum values (when appropriate). Some improvements/cleanup can still be made here but not a bad starting point. (would like to include min/max values and show specific details in a consolidated column)

Single parameter history

Original went from 9.2 forward showing history of the value.

New shows more GUC details including category and short description. Table of value history and another table with vartype history. Again, plenty of room for improvement now that the additional detail is available.

[rustprooflabs]

The biggest tradeoff with this change is the version history will now only go back to 10 instead of 9.2. I don't have the gumption to re-install those old versions to get the data needed. I started down that path and decided against it. That data would be interesting, but limited to pure curiosity. Postgres 9.6 is a few years past EOL already so the relevance isn't there for me. If someone wants to submit a PR to update the generate/compare process to include versions prior to 10 I'd be interested.