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.
Good point about ~PersistentTable. For a moment there, I thought I actually understood what was going on here. Now, I'm half-expecting memcheck to start crying foul.