FoundationDB/sql-layer — pull request #1114 by MMcM (2013-12-19 00:13:34+00:00)
Title: Begin to phase out Types from AIS

I am breaking this work up into separate changes to simplify the review. This one changes hundreds of files, but in mechanical ways. And furthermore does not change any actual behavior. Specifically,
* There were server.expressions and server.types.service packages, each half of the same module. Collapse them.
* Since the extent of types will be dynamic, there needs to be a types registry. It comes from that service, like the other dynamic cast / function registries. Anything that uses an ``AISBuilder`` needs to supply the types registry. Note that the builder doesn't use the registry in this branch.
* MNumeric.INT thinks that its name is "integer." That's the name of the closest standard SQL type. But the Types instance, and so persisted volumes, have int. As does the adapter. And the name in MySQL is int, with integer as a synonym, not the other way around. So change it to int and every place that knows this.
* Type parameters to builder.column are Long, not long, because they are allowed to be null, meaning N/A. And should not be supplied for types that do not have them. While presently ignored, this will become an error. Fix tests for int, in particular, which supply, among other things, 0L, (long) 0, Long.valueOf(0), or 4L.
* Similarly, types without charset and collation should not supply them. Because of further confusion about how a column inherits from the table, there wasn't an easy way to tell. Fortunately, it does not appear that non-string columns have these fields in the persistent AIS, only in tests.
* Loose collation mode currently means that the given collation is remembered but ignored in favor of binary. When this is part of the types3-type, it will mean that it was ignored at DDL time, because there is no way to store an illegal collation in a TInstance.