Capability reload-required tracking breaks down if the cap is reload-required because of removal

The WFCORE-1106 fix has a big flaw in how it tracks what capabilities are affected when a resource reports reload-required or restart-required. It only examines currently registered caps, but in the resource removal case the op that is calling reloadRequired() will have removed the cap in an earlier stage. So the fact the cap should be reload-required is not recorded.

The WFCORE-1106 integration test doesn't capture this because it uses write-attribute ops to trigger reload-required.

I discovered this when manually verifying the WFLY-4970 scenario was fixed. Turns out it wasn't.

I think the simple solution is to have the CapabilityRegistry cache the removed capabilities and also use that cache when checking what caps are affected by reload/restart required. The cache can be cleared on each publish or rollback of the registry because the data does not need to be retained beyond the span of the op that is making the changes.