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`.
Merge pull request #939 from slick/tmp/nested-options4

Nested Options