Adds simple support to translates LIKE ANY and LIKE ALL expressions

- Fix macaddr8 mapping
- Fix cidr mapping to (IPAddress, int)
- Split out from #407

- A future PR could look more thoughtfully at operator precedence overall
  - Either at generation time or as an analytical stage.
  - See:https://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-PRECEDENCE-TABLE

- Updates tests that check for SQL affected by this PR.

When a custom binary operator uses a standard comparison operator (`=`, `<>`, `<`, `>`, `<=`, `>=`)
EF Core will generate a pattern that causes a syntax error in PostgreSQL.

Example SQL:
```sql
WHERE x."Inet" < @__inet_1 = TRUE
```

This patch adds logic to check if the custom binary operator is one of the standard
comparison operators. If so, it wraps the expression in parenthesis.

Example SQL (patched):
```sql
WHERE (x."Inet" < @__inet_1) = TRUE
```

While it seems like this could be avoided by having the custom translator construct
a standard `Expression.LessThan(Expression,Expression)`, this causes an error to be
thrown...because the binary operator isn't defined.

Example stack trace:

```
System.InvalidOperationException : The binary operator LessThanOrEqual is not defined
  for the types 'System.Net.IPAddress' and 'System.Net.IPAddress'.
  at System.Linq.Expressions.Expression.GetUserDefinedBinaryOperatorOrThrow(...)
  at System.Linq.Expressions.Expression.GetComparisonOperator(...)
  at System.Linq.Expressions.Expression.LessThanOrEqual(...)
```

Related:

- https://github.com/aspnet/EntityFrameworkCore/issues/9143
- https://github.com/npgsql/Npgsql.EntityFrameworkCore.PostgreSQL/pull/323#pullrequestreview-101049961

When scaffolding, we have an Npgsql-specific IndexMethod annotation to
represent PostgreSQL's index methods. Previously, we would always
output this annotation on indices, even when the method was the
default (btree); NpgsqlAnnotationCodeGenerator would elide it as by-
convention.

Although this is cleaner, it caused issues whenever two indices where
defined on the same column:
https://github.com/aspnet/EntityFrameworkCore/issues/11846#

We now scaffold the annotation only for non-default index methods as a
workaround; the issue should now affect much less people.

Fixes #228

- Bug:
  - Input:  PgFunction("abbrev", typeof(string), new [] { inetExpression }) // x.Inet
  - Before: abbrev("x"."Inet",)
  - After:  abbrev("x"."Inet")

- Also includes general cleanup to match project style, remove unused using-statements, etc.

Based on https://github.com/npgsql/npgsql/pull/1939#discussion_r189436527.

Note that this commit removes subtype mapping handling. (#420)

Following https://github.com/npgsql/npgsql/pull/1937

Fixes #411

Instead of an interface, to allow easily adding methods in the future
without any breakage.

Adding some docs info on range operator translations + some additional edits.

Bug fix for 502ce2aa. NpgsqlRangeTranslator uses nameof(...) without checking the declaring type. This returns the unqualified name, such that all methods named Contains that reach this translator are handled. This commit adds a check to screen for the declaring type.

Closes #333

Closes #335

Allows users to register external Npgsql plugins which can add type
mappings and method translators (for now).

Closes #300

Fixes #400

Added PgFunctionExpression to allow generating function calls with named
parameter notation.

Closes #173

Closes #242

Various scenarios were broken

Fixes #365

Ignore a hardcoded list of tables (e.g. support table created by
PostGIS).

Fixes #400