Backend cake with path-dependent types in driver - almost working.

- ImplicitQueryable has not been adapter to this model.
- Writing a driver-independent DAO is hard due to the path-dependent
  types for the backend.
Don't use path-dependent types for the Backend from the Driver.

In some cases (e.g. writing a DAO which abstracts over multiple
drivers) those path-dependent types can get really ugly. Having a
single path-dependent Backend in the driver wouldn't buy us much,
anyway. We'll either keep the backends decoupled or integrate them
(and the direct embedding) into the driver cake later.
Expose Database in JDBC Session and add UnmanagedSession
Refactor BasicProfile into BasicProfile, SqlProfile and JdbcProfile
Move SQL utils down from JdbcProfile to SqlProfile
Remove some cruft
Allow building with JDK 6 and JDK 7
Add type information to all standard library calls
Print types of Typed nodes in AST dumps
Further disentanglement of AST/compiler and lifted embedding.

Remaining issues:
- TableNode depends on ShapedValue
- ForceOuterBinds depends on Column
- SlickBackend depends on Shape and ShapedValue

This refactoring also removes some clutter and adds a TypeMapper[Char].
Further preparations for moving type information into the AST
Always perform TypeMapperDelegate lookup through typeInfoFor
Remove TypeMapper abstraction.

TypeMapper becomes ast.TypedType (plus BaseTypedType, OptionTypedType and
NumericType) but it does not support the TypeMapperDelegate lookup any
more. Instead, both ast.StaticType and JdbcType (the former
TypeMapperDelegate) implement TypedType. Implicits for StaticType can be
used in the lifted embedding, AST and compiler. Implicits for the
JdbcTypes are provided by the driver for use in user code. The driver also
knows how to map the few remaining StaticTypes to the right JdbcType.

This removes the dependency on JDBC-specific types from the lifted
embedding. Profiles other then JdbcProfile can provide their own set of
types along with their own type implementation.

The downside of this change is that there is no mechanism to prevent users
from using types from a different driver (even if it implements an
unrelated profile). This will lead to subtle runtime errors if the
types have compatible implementations (e.g. they are all JdbcTypes) and
to runtime exceptions during type lookup when the implementations don't
match. But the SimpleQL imports make it very easy to use the right types
and it requires some work to use the wrong ones.
Fix op handling in Column.forNode and use this instead of WrappedColumn.

3 uses of WrappedColumn remain where the type information is overridden.
They can be replaced by Column.forNode once all type information has been
moved into the AST.
Merge branch 'master' into topic/backend-refactoring

Conflicts:
	src/main/scala/scala/slick/session/Session.scala
Simplify construction of typed standard library calls
Merge branch 'master' into topic/backend-refactoring
Merge branch 'master' into topic/backend-refactoring

Conflicts:
	slick-testkit/src/main/scala/com/typesafe/slick/testkit/tests/MapperTest.scala
	src/main/scala/scala/slick/driver/AccessDriver.scala
	src/main/scala/scala/slick/lifted/ExtensionMethods.scala
	src/main/scala/scala/slick/lifted/TypeMapper.scala
Remove nodeMapNodes and simplify mapOrNone
Remove the non-"Simple" Node, DefNode and RefNode versions.

This merges SimpleNode into Node, SimpleDefNode into DefNode, and
SimpleRefNode into RefNode.