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.
It took some trial and error to make this work.  Some methods of shared_ptr require a complete definition of the type parameter T (e.g., `reset`), and some don't (`swap`).  I think it has something to do with T's destructor needing to be called, but I'm still a bit baffled because T's destructor would potentially need to be called anyway when the PersistentTable is destroyed.

In any case this seems to work okay and lets us keep ExecutorVector un-exported for now.