Fix initialization order problem in generated code
Merge pull request #677 from slick/tmp/fix-codegen-init-order

Fix initialization order problem in generated code
Support casts to boolean and double in Access.

Fixes failing test AggregateTest.testGroupBy.
Merge pull request #681 from slick/tmp/access-casts

Support casts to boolean and double in Access.
Add documentation for `into` method
Merge pull request #687 from slick/tmp/into-docs

Add documentation for `into` method
Emulate empty join conditions where needed.

Appending the dummy condition "on 1=1" works almost everywhere, except
in Access, where the condition has to reference columns from both sides
of the join, so we have to thread the dummy "1" values through the
sub-queries.

Fixes Typesafe support ticket 3140.
Test in JoinTest.testNoJoinCondition.
Fixed issue #554 (ZIP joins)
Merge pull request #708 from Radsaggi/tmp/issue554

Fixed issue #554 (ZIP joins)
Fixed issue #698 (MappedColumnType broken for Char)
Add test for broken mapping to Char
Merge pull request #712 from Radsaggi/tmp/issue698

Fixed issue #698 (MappedColumnType broken for Char)
Simplify Invokers

- Remove parameterized Invokers. They hugely complicate the API
  (overloads for UnitInvoker; some UnitInvoker methods require
  parens, others forbid them) and the implementation.

- The Lifted Embedding did not expose parameterized Invokers anymore
  since 2.0. With this change, the distinction between QueryInvoker,
  UnitQueryInvoker and MutatingUnitInvoker (for applied compiled
  queries) goes away.

- Adapt StaticQuery to the new model. The API stays mostly compatible.
  StaticQuery is now only a builder for the query, the actual execution
  is done by a new StaticQueryInvoker. Parameterized StaticQuery objects
  have to be applied first to get the Invoker. For compatibility with
  the old API, there is an implicit conversion for StaticQueries with
  Unit parameters.
Simplify Option handling in JdbcProfile.

- Remove the useless TypeInfo abstraction in BasicProfile. It is not
  needed at this level. Sub-profiles should have more flexibility for
  implementing types.

- Represent only base types with JdbcType, not Option types. JDBC is
  based on optionally nullable base types. Making this more explicit in
  the handling of Option columns should simplify the implementation of
  more efficient "fast path" mapping converters in the future.

- JdbcType.nullable is no longer needed.
Remove zero values from ScalaType.

We used them as default values in MemoryDriver but this is not necessary
for compatibility with SQL databases. Inserting into a row without an
explicit value or an explicit default defined in the schema is always
equivalent to inserting NULL. On a real database it leads to a
constraint violation if the column in question is not nullable. With
this change, MemoryDriver also uses null as the default for all data
types. Constraints are not enforced (in any scenario in MemoryDriver).
Merge pull request #700 from slick/tmp/support-3140

Emulate empty join conditions where needed.
Merge pull request #694 from slick/tmp/simplify-invokers

Some cleanup work
Encode the type constructor for the unpacked collection type into Query.
Simplify Query internals.

- NonWrappingQuery is not really needed. Its use in foreign keys was
  completely unnecessary. TableQuery and the empty Query can extend
  Query directly. All other Query values are of type WrappingQuery.

- With foreign keys cleaned up not to require NonWrappingQuery, we can
  get rid of the special case for that in Query.apply. That makes
  Query.apply identical to Query.pure, so we deprecate Query.pure.

- Rename "unpackable" to "shaped". It's been a long time since the type
  was called Unpackable.

- Introduce Query.empty as the empty query instead of using the Query
  companion object for this purpose.
Allow Query result type constructors to be changed.

- The Query#to method switches to a different type constructor.

- "to" is backed by the new "CollectionCast" Node which changes the type
  constructor. The node itself gets erased in hoistClientOps and is
  ignored by QueryInterpreter.

- We use a ClassTag to track the result type for inspection at runtime.
  If it is a subtype of Seq, the collection is assumed to be sequential
  (i.e. order matters), if it is a subtype of Set, the collection is
  unique (i.e. it does not allow duplicate elements). This
  information can be used later to optimize query translation.

- The CanBuildFrom instances for a type constructor change in "to" are
  required to build a collection with element type Any. This prevents
  the use of optimized builders for specific element types but it
  greatly simplifies the handling of type constructors in the AST.
  Otherwise any operation that could change the element type would have
  to carry a new type constructor that overrides the inherited one. The
  simplified approach is limited to building collections that are either
  contravariant or erased, so it precludes the use of Arrays. As an
  approximation of this precondition we limit the type constructors that
  are allowed by "to" to those extending Iterable.

Tests in ExecutorTest.testCollections.