Allow non-literal constant values for Query.take and Query.drop

- Change Take, Drop, Comprehension, and the TakeDrop extractor to use
  Node instead of Long.

- Add helper method QueryParameter.constOp to perform a computation
  on two Long values inside of LiteralNode or QueryParameter nodes. We
  use it for computations that are necessary for fusing Take and Drop
  operations and computing boundaries for them.

- Add overloads for Query.take and Query.drop which take Long and
  ConstColumn[Long] arguments (in addition to the existing Int versions)

- Add specializeParameters phase which creates a ParameterSwitch node
  for detecting edge cases in parameters that need to be compiled to
  different statements. It is used by DerbyDriver and HsqldbDriver.

Test in PagingTest.testCompiledPagination. Related to #718.
Merge pull request #764 from slick/tmp/non-literal-take-drop

Allow non-literal constant values for Query.take and Query.drop
Improve Inserts

- Introduce a new CompiledInsert abstraction in BasicProfile. Drivers
  can implement it with a compiled AST or a more abstract object that
  can compile to different kinds of insert statements and cache them.

- JdbcProfile provides its own JdbcCompiledInsert class caches
  statements on first use.

- Introduce StreamableCompiled (extends RunnableCompiled) and
  StreamingExecutable (extends Executable) to distinguish compiled
  and runnable collection-valued queries from other (record-valued
  and scalar) queries, and provide the element types. StreamableCompiled
  is needed here for inserts (you can only insert into collections) and
  can also be used later for a streaming Executor that can fully replace
  Invoker.

- Provide a StreamingExecutable for TableQuery and BaseJoinQuery (#746)

- Allow inserts from StreamableCompiled queries. Since the actual cached
  statement is contained in the JdbcCompiledInsert produced on demand
  by the StreamableCompiled, this removes the need to cache the
  InsertInvoker for efficient reuse of insert statements, thus providing
  the same kind of abstraction for cached inserts that was already used
  for query, update and delete operations since Slick 2.0.

Tests in TemplateTest.testCompiled (inserting into a Compiled query,
compiling TableQuery and BaseJoinQuery). Fixes issue #746.
More improvements for Inserts.

- Split the code generator and mapping compiler off from InsertCompiler,
  using a standard CodeGen phase instead. CodeGen also gains a
  skeleton implementation that can be used by all existing profiles.
  (There is no need to inherit from CodeGen at all if it doesn't fit.)

- Allow efficient building of insert statements from source queries
  in InsertBuilderResult.

- Fix a bug in FullInsertInvoker.insert(query) that caused the query to
  be compiled twice.

- Add an extra `baseIdentity` TableIdentitySymbol to TableNode which is
  initialized with the same value as `identity` but keeps that value
  throughout the compilation. This TableIdentitySymbol can be used to
  check if two TableNodes point to the same database table. So far we
  used the unqualified table name for that (which was wrong).

- Clean up type-checking and the use of symbols in Insert nodes.

- Allow inserts from pre-compiled queries (as the data source) in
  addition to the ability to use pre-compiled queries for the target
  (as added in the previous commit).

- InsertColumns can now have zero or more paths. For skipped columns,
  an empty InsertColumn is generated, indicating that the value is
  part of the result type (and thus the ResultConverter) but is gets
  discarded. InsertColumns with zero paths or more than one path are
  compiled to a CompoundResultConverter.

- Remove special handling for setting full and skipping data from
  ResultSetConverter and compile different converters instead.
  Ironically, that's what I tried first a couple of months ago and then
  aborted because it seemed like a dead end. Now the approach I took
  instead turned out to be the dead end.

Test in InsertTest.testSimple (inserting from a compiled query).
Add insertOrUpdate to InsertInvoker.

- Refactor InsertInvokers: Split them off from InvokerComponent into a
  separate InsertInvokerComponent because in the JDBC implementations
  they contain a lot more code than all other Invokers combined. A
  separation into traits and protected implementation classes makes
  them more readable and allows InsertInvokers for "return ... into"
  to always work out of the box without extra customization in drivers.

- Remove the unnecessary "forced" parameter from ResultConverter.set.

- Add an UpsertBuilder to JdbcStatementBuilderComponent which builds a
  standard SQL MERGE statement by default.

- Add CheckInsertBuilder and UpdateInsertBuilder for use in emulated
  client-side insertOrUpdate operations.

- Add JdbcProfile.capabilities.insertOrUpdate to indicate native
  insertOrUpdate support in a driver.

- Move scalarFrom out of QueryBuilder to JdbcProfile (UpsertBuilder
  needs it, too).

- Make ResultConverterCompiler stateless and use the index from the
  path into the ResultSetMapping instead of enumerating columns there.
  In the future, this could also be used for query operations to allow
  transformations of client-side mappings.

Driver support (which makes you wonder why we even bother with native
MERGE support, given how limited it is):

- Hsqldb uses the standard MERGE syntax but cannot return generated
  keys from a MERGE, so we have to use the client-side emulation when
  returning keys.

- MySQL requires a custom upsert command with good semantics. We can
  use it in all cases.

- H2 and SQLite require custom upsert commands and can only perform
  upserts with forced insert semantics, so we have to use the
  client-side emulation for tables with AutoInc columns.

- PostgreSQL uses a multi-statement server-side emulation.

- The client-side emulation is used for Access and Derby.

Fixes issue #6. Tests in InsertTest.testInsertOrUpdatePlain and
InsertTest.testInsertOrUpdateAutoInc.