RFR: 8130931: refactor CardTableModRefBS[ForCTRS]

[Kim Barrett]

Please review this refactoring of CardTableModRefBS and
CardTableModRefBSForCTRS.  The changes are in two stages, with
separate webrevs to make it easier to review.

The first stage eliminates some friend declarations from
CardTableModRefBS.

- BytecodeInterpreter doesn't need to be a friend.
- CheckForUnmarkedOops changed to use public byte_for_const().
- SharkBuilder changed to use public dirty_card_val().
- GuaranteeNotModClosure does not exist.
- CardTableRS changed to be a friend of CardTableModRefBSForCTRS. 
  Changed some references to static members of CardTableModRefBS
  to work around bugs in clang and Visual Studio [1].

Only the VMStructs friend declaration is retained.

The second stage moves some functionality that is specific to or only
used with the ForCTRS class from the base class to the ForCTRS
subclass. It also moves the ForCTRS class into its own files, separate
from the base class.

We could further split below CardTableModRefBSForCTRS, with support
for parallel card scanning (used only by CMS) being in another class.
That split already partially exists in the source code structure, with
some relevant functions being defined in CMS-specific
parCardTableModRefBS.cpp. That restructuring is being left for later.

CR:
https://bugs.openjdk.java.net/browse/JDK-8130931

Full webrev:
http://cr.openjdk.java.net/~kbarrett/8130931/webrev.00/

De-friending webrev:
http://cr.openjdk.java.net/~kbarrett/8130931/remove-friends.00/

Refactoring webrev:
http://cr.openjdk.java.net/~kbarrett/8130931/refactor.00/

Testing:
JPRT
local specjbb2000 & specjbb2005 with G1, CMS, and Parallel GCs
Aurora Runtime+GC Nightly & VM quicklist, using CMS (in progress) 
Aurora Runtime+GC Nightly & VM quicklist, using G1 (in progress) 

[1] Both clang and Visual Studio are more restrictive than the
standard specifies for friend access to static members of base classes
of the class granting friendship. The relevant standardese is C++03
11.5 [class.protected] (C++11 11.4). At least in the case of clang,
this non-conformance is intentional. For gory details, see:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52136
https://llvm.org/bugs/show_bug.cgi?id=6840
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-June/thread.html#9301

Having read all that, I'm inclined to agree with the clang folks - the
special dispensation for static members is very strange. But so far
the clang folks seem to be just ignoring the problem, and don't seem
to have opened a DR for it.

I don't have any similar background information for Visual Studio's
non-conformance.