Remove the Column type.

A `Column[T]` is a `Rep[T : TypedType]` (or, in the context of code
using a driver, more appropriately a `Rep[T : ColumnType]`).

- Remove all dependencies on Column and replace them with Rep, in
  particular in: extension methods, CanBeQueryCondition, Case,
  OptionMapper, ColumnOrdered, TupleSupport.

- Deprecate the implicit conversion from Column[T] to Column[Option[T]].
  This is only semi-related to this change but seems to be a good idea.
  A few unit tests and the code generator relied on this conversion for
  foreign key definitions. These are made explicit now, using `.?` for
  Option-lifting.

- Change CanBeQueryCondition, Case, OptionMapper, ColumnOrdered and
  TupleSupport to use Rep.

- Provide a Shape for Rep-based columns and remove the old one.

- Make primitive types pack to ConstColumn instead of Column. This makes
  sense even without the rest of this refactoring. A primitive value is
  always an execution-time constant.

- Make Column[T] a deprecated alias of Rep[T].

- Remove the unnecessary Column subtypes Case.TypedCaseWithElse and
  ParameterColumn.

- Remove the `asc` and `desc` methods from Column. The implicit
  conversion to ColumnOrdered is sufficient.

- Allow any Rep instead of only Column in the tuple extension methods
  `~` and `~:`.

- Improve scoping of `Shape` implicits for lower compilation times.
Lifted Embedding encoding of nested and multi-column Option types:

- Add definitions of flatMap and flatten

- Replace ConditionalExpr and IfThen by IfThenElse. The special Option
  type handling is now done in directly in Case so that it does not
  interfere with type-checking of IfThenElse in more complex scenarios
  (like in the new .filter method for Option columns).

- Implement Option lifting and catamorphism: All extension methods are
  based on `fold` and `flatMap`, so they all translate to OptionFold
  nodes.

- encodeRef (in various places) needs to take a Node, not just Path.
  We’ll get other kinds of nodes in OptionApply.

- The new expandSums phase handles the translation of OptionApply and
  OptionFold.

- Use a dedicated RebuildOption node for the client-side Option
  rebuilding. This is necessary because the optional data columns’
  types are not option-extended, so they must not be read if the
  discriminator is not 1 (which would be the case when using a
  TypeMapping).

- The new expandConditionals phase expands the multi-column SilentCast
  and IfThenElse nodes created by expandSums.

- Create SilentCasts for column types in createResultSetMapping.
  Otherwise the original column types before option-extension are lost
  and we can’t build the right converters in codeGen.

- Check in expandSums that GetOrElse is not called on non-primitive
  Option values. In the Lifted Embedding extension methods we can
  enforce that it is only available for Options of primitive column
  types as seen at the call site but that does not prevent it from
  being called inside a HOF like .map which translates it to an
  operation on a non-primitive Option.

I considered a few different encodings. For plain types, the Option
lifting and unlifting is straight-forward:

Plain types: Wrap and unwrap Option
  Int <-> Option[Int] <-> Option[Option[Int]]
  (Int, String) <-> Option[(Int, String)]
    <-> Option[Option[(Int, String)]]

The different encodings for lifted types are:

1) Simple Rep types: M <: Rep[_] -> Rep[Option[U]], P <- Rep[Option[M]]
     Rep[Int] <-> Rep[Option[Int]] <-> Rep[Option[Option[Int]]]
     (Rep[Int], Rep[String]) <-> Rep[Option[(Int, String)]]
       <-> Rep[Option[Option[(Int, String)]]]
   Table types:
     X -> Rep[Option[(Int, String, String)]]
       -> Rep[Option[Option[(Int, String, String)]]]
   Problem: No way back! (pack º unpack != identity)

2) All Rep types: T <-> Rep[Option[T]]
     Rep[Int] <-> Rep[Option[Rep[Int]]]
       <-> Rep[Option[Rep[Option[Rep[Int]]]]]
     (Rep[Int], Rep[String]) <-> Rep[Option[(Rep[Int], Rep[String])]]
       <-> Rep[Option[Rep[Option[(Rep[Int], Rep[String])]]]]
     X <-> Rep[Option[X]] <-> Rep[Option[Rep[Option[X]]]]
   Similar to Query.groupBy where a nested Rep (Query) shows up in the
   lifted type. In our polymorphic embedding, the crucial difference is
   product types vs sum types. Problem: This clashes with the existing
   types for Option-based columns

3) Compromise: Rep[Option[P]] is allowed for any M *and* any Rep[M].
   Restricting it to option of P types ensures that we can only lift a
   fully packed type into a Rep[Option[_]]. Option lifting/unlifting
   always creates/removes Rep[Option[_]]. Problem: Multiple
   representations require extra extension method conversions and make
   it hard to abstract over Options

4) Compromise: Lift Rep[T] with the first method, other shapes with the
   second:
     Rep[Int] <-> Rep[Option[Int]] <-> Rep[Option[Option[Int]]]
     (Rep[Int], Rep[String]) <-> Rep[Option[(Rep[Int], Rep[String])]]
       <-> Rep[Option[Rep[Option[(Rep[Int], Rep[String])]]]]
     X <-> Rep[Option[X]] <-> Rep[Option[Rep[Option[X]]]]
   Abstract over Option lifting/unlifting with an OptionApply typeclass.

Version 4 is actually implementable with little overhead and without
breaking existing types and extension methods, so that's what we're
doing here. Unfortunately, it requires a more stringent ordering of the
core Shape implicits which can only be implemented by making them
available through the Shape companion object (like it used to be in
Slick 2.0), eliminating the compile-time performance improvements we
made in 2.1 with more narrowly scoped Shape implicits.
Add Option-extended joins:

- Definitions for new left, right and full outer joins with correct
  types.

- The new join types get translated in expandSums.

- emulateOuterJoins needs to run after expandSums, and thus also after
  forceOuterBinds, so we add an extra run of forceOuterBinds in
  emulateOuterJoins.

- Improve debug logging for Symbols and Types to make it much more
  concise and readable for bigger type signatures.

- Deprecate old join operators and change test cases accordingly

- Generate Rep.Some instead of .? calls in AbstractSourceCodeGenerator.
  Not deprecating .? yet because foreign key definitions get uglier
  with Rep.Some. We need to decide whether or not to deprecate a) the
  .? operator, and b) the implicit Option lifting.

- Fix Comprehension typing bug:
  - If there is at least one `from` clause:
    - Take type constructor from the first `from`
    - If a `select` exists, take the element type from that, otherwise
      from the last `from`
  - Otherwise: Take the entire type from `select`

- Run expandTables much earlier (after inferTypes) and handle
  OptionTypes and MappedScalaTypes there by creating Option mappings
  (using OptionApply) and TypeMappings.

- Since table types in the top-level result have already been
  eliminated before createResultSetMapping, it doesn’t need the special
  handling for TableExpansions anymore.

- Eliminate TableExpansions in expandTables instead of expandRecords to
  keep the tree smaller. This requires a change in forceOuterBinds to
  wrap Tables instead of TableExpansions.

- Expand and retype untyped LiteralNode.nullOption values already in
  expandSums instead of expandConditionals.

- Perform expandConditionals directly after expandSums. There is no
  need anymore to first run expandRecords.

- In order to optimize translated Option operations correctly, we now
  use a special type OptionDisc for the discriminator columns. Option
  operations can thus be recognized in expandSums after Option
  expansion. We use this information to fuse some Option operations.

- Introduce the concept of erased types for OptionDisc. Since such
  types are irrelevant in codeGen and at the client side, we use
  values of the underlying type Int directly without wrapping. The
  OptionDisc trait is only used as a phantom type. The corresponding
  Slick type is an ErasedScalaBaseType.

- Simplify LiteralNode and provide useful implementations of `equals`
  and `hashCode`.
Avoid indenting blank lines, to avoid trailing whitespace.
Make comment format match others in file.
Ensure generated file ends with a newline character.
Merge pull request #1001 from bensymonds/codegen-trailing-whitespace

Avoid indenting blank lines, to avoid trailing whitespace.
Merge pull request #939 from slick/tmp/nested-options4

Nested Options
Fix broken build due to merging nested options support
Merge pull request #1006 from slick/tmp/nested-options4-fix

Fix broken build due to merging nested options support
Add primitives and configuration for async execution of blocking I/O

- AsyncExecutor manages a pooled ExecutorService and provides an
  ExecutionContext for it. It is optimized for blocking I/O calls.

- The Database factory methods for JdbcBackend take an additional
  AsyncExecutor argument, falling back to an executor with a default
  configuration.

- Database.forConfig allows the executor parameters to be configured
  through config keys, automatically using the correct thread pool size
  for a connection pool.

- DatabaseComponent provides asynchronous execution for all profile
  levels. Implementors are required to supply an ExecutionContext
  suitable for I/O on a particular Database. DistributedBackend and
  HeapBackend use the global ExecutionContext.

- DatabaseComponent provides a close() method for all profile levels.

- TestKit and DBTest close all Database instances properly to ensure
  that the thread pools for async tests are shut down.

Test for async execution primitives in ExecutorTest.testAsyncExecution.
Add HikariCP support in addition to BoneCP.
Remove BoneCP support and drop configuration compatibility with Play.

With the modularization in Play and the needs of Reactive Slick, the
goal is to use Slick’s own pool configuration in Play, thus trading
configuration compatibility in Play across different database frameworks
for consistency of database configurations within the same framework
across different kinds of applications (Play and non-Play).

We keep some old config key names where the corresponding HikariCP
option names are unnecessarily verbose. Both naming styles are supported
for both, HikariCP and the non-pooled DriverJdbcDataSource.

Old (already available in Slick 2.0) keys which are no longer officially
supported, and their replacements:
  autocommit     -> autoCommit
  isolation      -> transactionIsolation
  defaultCatalog -> catalog
For compatibility with 2.0, these keys are still accepted for non-pooled
configurations but they trigger a log warning stating that the key is
deprecated.
Remove the option to disable auto-commit for new connections.

Slick’s internal transaction handling requires all new connections to be
in auto-commit mode, so there is no reason to disable auto-commit. This
is also the default according to the JDBC specification. (Connection
pools usually have an option to disable auto-commit but the config keys
do not apply to connections created on top of an externally managed
DataSource anyway).

We also remove HikariCP’s `isolateInternalQueries` options which is
meaningless in auto-commit mode.

Using the old `autocommit` config key (which was already supported in
Slick 2.0) now triggers a log error stating that it is no longer
supported.
Simplify thread pool configuration:

For asynchronous execution, `numThreads` is the main option that
determines scaling. Connection pool sizes are now derived from it by
default (instead of the previous way of starting with the connection
pool size and deriving the thread pool size).
Simplify connection pool configuration
Use HikariCP by default (instead of no connection pooling):

- Disable pooling in TestKit reference config

- Rename `pool` parameter to `connectionPool` (to avoid confusion with
  the thread pool)

- Remove deprecation warnings for `autocommit` and `defaultCatalog`
  parameters. With HikariCP being the default now, there is no way to
  be compatible with an old configuration.