Connect capped collections front end to back end

This change set allows the user to create a table with a constraint like `LIMIT PARTITION ROWS <n> EXECUTE (DELETE ...)`, and have the delete statement execute in the back end when an insert is about to occur that would exceed the current tuple limit for the table.  

The constraint can also be added via an ALTER TABLE ... ADD ... or a live catalog update.  Much of the changes here are testing for that.

In the EE, when the catalog is being loaded or updated and a table has a limit delete statement, the EE will grab the statement's compressed JSON fragment, create an ExecutorVector, and hang it off of the persistent table.  The insert executor will then ask the VoltDBEngine to execute the fragment when an insert will overflow the table.

Plan fragments are stored in the catalog in compress format, encoded as base-64.  I had to add a new JNI call to decode the plans.  Thus far we haven't had to do any deserializing of plans in the EE (as far as I know).  

I also had to do some re-factoring of the code that constructs executor vectors, since now we build them in two ways (the normal way during execution, and when loading/updating the catalog).  I added a static factory method in ExecutorVector that encapsulates construction.

I also ripped out some the "magic values" that simulated the front end work, since it's not needed anymore.
You should log a ticket about this -- that there should be some catalog report notation that shows that an index is used in its table's LIMIT EXECUTE DELETE statement, so that the index won't appear to be unused. There is already a similar issue logged for indexes that are used in mat view upkeep.