EE support for LIMIT PARTITION ROWS EXECUTE DELETE...

Adds a couple new methods to `PersistentTable`: `hasPurgeFragment` and `getPurgeFragmentId`.  The insert executor will request the `VoltDBEngine` to execute the purge fragment if the table is at its row limit.

My current thinking is that the purge fragment for a table should be cached like any other fragment.  The purge fragment might be executed often, or very infrequently, so our LRU caches seem well-suited to this.  This approach also minimizes changes in the back end, as well as changes to catalog.  (Currently we represent expression trees in the catalog, but there is no precedent for a complete fragment.)

It's still unclear to me how we might handle the problem of mapping a table to its purge fragment id, especially since the purge fragment id might change when it's removed and then re-cached.


Yes, I think the purge fragment should get a normal fragment id, at least from the perspective of the EE.  

For normal fragments from stored procedures, the id is assigned arbitrarily.  When the fragment is removed from the cache and then re-cached, it will have a different id.  This is okay since the fragment id comes from Java, and Java will tell the EE to execute the fragment with the new id.  Java will pre-load the fragment into the `ActivePlanRepository`, so we are guaranteed to have the fragment corresponding to any id that the EE asks for.  There is an assertion in the code that backs this up.

So how will the EE know which fragment id to use when it wants the purge fragment?  I think the best way would be to make the fragment id for a table's purge fragment static so that it never changes.  There could be a map in Java that maps a table to its purge fragment id.  Then the purge fragment id can be sent to the EE in the catalog, and can be stored in a field in `PersistentTable`.