Timestamp and Date classes which work in the catalyst DSL.

These Timestamp and Date classes support the usual comparison operators, so the can be used in catalyst Expressions.  The come with implicit conversions to and from the underlying Java classes.  They also have a convenient initializer which accepts a String.

Additional implicit conversions fix an issue with the DSL where expressions like 0 < 'x are not recognized.

An independent change adds a method to Row for creating a row from a sequence of Strings and a schema.
OK.  That makes sense and avoids problems.

But how about if they are still imported as org.apache.spark.sql.Date and org.apache.spark.sql.Timestamp at the top level?  My reasoning is based on providing consistency for a user.  A user is not required to use RichInts or RichStrings as literals in a catalyst expression.  So why would they expect to have to use RichDates or RichTimestamps?