SCRAM client vs pgjdbc packaging

Hello,

Álvaro has implemented SCRAM support for pgjdbc (see
https://github.com/pgjdbc/pgjdbc/pull/842 ), and it would be great to merge
that.

However, there might be a packaging issue.

Technically speaking, the client is implemented in
https://github.com/ongres/scram (BSD 2-clause "Simplified" License).

I expect SCRAM to become the main way to authenticate, so it would be nice
if pgjdbc could just work with no need to add different jars to the
classpath.

The question is how should we deal with the dependency.

1) We could make it optional & dynamic. That is we refrain from including
the client to pgjdbc artifacts. In case backend is configured for SASL,
pgjdbc would bail out with "please add scram-client-whatever.jar to the
classpath" error.
The drawback is pgjdbc would require a certain versions of scram-client, so
it might cause troubles in future if application code and pgjdbc would
require different incompatible versions of the client.

2) We could incorporate scram-client to the pgjdbc artifacts, so it would
just work if backend requests SASL. This option enables us to repackage the
client with our own name (e.g. org.postgresql.ongress.scram...), so it will
enable applications to use scram-clients of their choice.

I'm inclined to #2 (incorporate scram-client at build time), however I am
not sure if it will ripple via some packaging issues.

Note: I expect we might want to add new dependencies later (e.g. for "SASL
string preparation", or Netty for networking layer), so it would be nice to
know limits/edge packaging cases.

Vladimir