Front-end support for LIMIT ROWS DELETE statements

The first commit you have already seen here on GitHub.  The second completes the ticket by doing error checking, planning the statement, and logging the explained plan:
* The HSQL parser stores the text of the DELETE statement in the VoltXML that it generates
* `DDLCompiler` generates VoltXML from the text of the DELETE statement to verify that the statement is a DELETE that targets the correct table
  * The statement is then saved in the catalog as a child of the Table 
* After `VoltCompiler` compiles stored procedures, it proceeds to compile any DELETE statements designed to help enforce the ROW LIMIT constraint
  * It's at this time that the explained plan is logged.
There are a couple of options here, none of them ideal for this particular case.  `Statement?` isn't ideal since it doesn't convey ownership.  The generated catalog code in Java assumes that I already created an instance of `Statement` somewhere else (and some other catalog object owns it).  I also have to set the reference to the parent catalog object explicitly.  On the C++ side, the Statement object will be leaked, since it's assumed that it will be freed from some other destructor.  On the whole, this approach just felt wrong to me.

On the other hand, when I use `Statement*`, the method `CatalogMap.add` does a lot of nice things for me, including setting the parent reference, creating the path for the Statement, and catgen also ensures that `Table` will free the map entry in its C++ destructor.

It seems to be an invariant in the `CatalogType` hierarchy that ownership is conveyed with maps, and I didn't want to diverge from this.  I think an ideal solution would be to enhance catgen to convey ownership of an optional (quantity 0 or 1) object, but that's more than I wanted to bite off right now.