Cleanup PGProperty, sort values, and add some missing to docs

[sehrope]

Alternative to #1504 (I'll close that one out in a min in favor of this). This PR is rebased atop the latest additions for new properties and docs. It passes checkstyle and tests. Should not have any end user change as the only thing modified is the declaration order of the PGProperty enums and I can't imagine the previous sort order being used for anything (it was effectively random anyway).

Summary of PGProperty changes:

• misc: Remove variadic constructor for PGProperty values and split across multiple lines - Longer term we're going to need to add some more structured information to the PGProperty enum so this commit gets rid of the convenience variadic constructor as it'd just be confusing down the road.
• perf: Cache PGProperty values in a map by name - I noticed one of the methods does a loop through all the values to find one matching by name. This commit builds a static cache on class load so the lookups are always O(1). It also does a sanity check that no two entries have the same name.
• misc: Add PGProperty.getDescription() - Eventually required for automated docs.
• misc: Add PGProperty.isRequired() - Eventually required for automated docs.
• misc: Add PGProperty.isDeprecated() - Eventually required for automated docs. This is done via reflection of the @deprecated annotation so should work for any future deprecations as well.
• misc: Sort PGProperty enum values - This should eliminate most future merge conflicts as long as they continue to maintain the sort order for new values.

Stepping through the docs I noticed the following properties were either not documented or incorrectly referenced:

• docs: Correct receiveBufferSize and remove duplicate sendBufferSize
• docs: Add missing binaryTransfer property to head docs
• docs: Add missing databaseMetadataCacheFields and databaseMetadataCacheFieldsMiB to head docs

This PR does not go through the connection property docs themselves to sort things. There's too many changes that I don't think it's worth the effort. Better to go straight to creating automated docs based on the info that we now have in the enum. I'm going to open a separate issue to track automating the doc generation.