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.


Is that 8 spaces for the tab?