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.
Boost's shared_ptr uses checked_delete, which ensures that the thing being deleted is completely defined or else there will be a compile time error.  So we're not at risk of the destructor not firing here.  Also, I ran the memcheck job in Jenkins, and TestSQLFeaturesNew didn't show any leaks.

I'm still baffled though.  The only place where ExecutorVector is completely defined is from within VoltDBEngine.cpp.  So this must be the only place ~PersistentTable is called.  But as far as I can tell ~PersistentTable is deleted from Table::decrementRefcount, which is inlined in Table.h, but called from numerous places besides VoltDBEngine.

The shared_ptr seems to be doing its job, so I'm happy to chalk this up to dumb luck for now.