Revision 1645055

DERBY-6774 background post commit threads cause ASSERTS/errors on interaction with alter table add column

Renable the tests that were failing on some platforms, and adds tests that
were failing consistently in my environment (laptop, windows 7, ibm17). 

The fix was to insure that background threads waited on table intent lock 
before going to the conglomerate cache.

Before doing this an inconsistent conglomerate would sometimes be faulted into 
the cache between time when alter table abort was invalidating the cache and 
abort had finished backing out the alter table. Then a subsequent alter table 
would fail as it correctly passed in that there was 1 existing column, but the
conglomerate cache thought there were 2 columns.