Check CPU features in the Simulator and Disassembler.

This is implemented using a new decoder visitor, CPUFeaturesAuditor. This
visitor holds a set of features required by the last-decoded instruction, a set
of features seen since construction (or 'ResetSeenFeatures()'), and a set of
features that are considered to be available. This visitor can be used by
itself, but its main purpose is to implement Simulator and Disassembler support
for CPUFeatures:

- The Simulator creates and attaches this visitor automatically, much like it
  does for the disassembly trace, so existing simulation use-cases require no
  special user interaction. The Simulator checks that each encountered
  instruction only uses available features.

  The Simulator also supports dynamic configuration of features, in a manner
  similar to the trace controls.

- The Disassembler does not directly interact with the CPUFeaturesAuditor, but
  the PrintDisassembler can be configured to annotate each instruction with
  required features that are missing from GetAvailableFeatures().

  The PrintDisassembler is used to implement Simulator trace, so a simulation
  failure due to missing feature support will be immediately preceeded by a
  corresponding PrintDisassembler annotation (when trace is enabled).

  No existing test uses the PrintDisassembler in this way, so this patch also
  adds 'TRACE_' tests to check that the features are appropriately formatted.

Change-Id: I3dc0e22f0a5bd3287ba1870539e018ff4a768a4b
diff --git a/src/cpu-features.h b/src/cpu-features.h
index f3b3b4b..e5c68ab 100644
--- a/src/cpu-features.h
+++ b/src/cpu-features.h
@@ -93,18 +93,29 @@
 //   - When the Assembler is asked to assemble an instruction, it asserts (in
 //     debug mode) that the necessary features are available.
 //
-//   - TODO: The Simulator assumes that all features are available by default,
-//     but it should be possible to configure it to either warn or fail if the
-//     simulated code uses features that are not enabled.
-//
-//   - TODO: The Disassembler disassembles all instructions that it knows, but
-//     it could be (optionally) configured to warn if the code uses features or
-//     instructions that are not available.
-//
 //   - TODO: The MacroAssembler relies on the Assembler's assertions, but in
 //     some cases it may be useful for macros to generate a fall-back sequence
 //     in case features are not available.
 //
+//   - The Simulator assumes by default that all features are available, but it
+//     is possible to configure it to fail if the simulated code uses features
+//     that are not enabled.
+//
+//     The Simulator also offers pseudo-instructions to allow features to be
+//     enabled and disabled dynamically. This is useful when you want to ensure
+//     that some features are constrained to certain areas of code.
+//
+//   - The base Disassembler knows nothing about CPU features, but the
+//     PrintDisassembler can be configured to annotate its output with warnings
+//     about unavailable features. The Simulator uses this feature when
+//     instruction trace is enabled.
+//
+//   - The Decoder-based components -- the Simulator and PrintDisassembler --
+//     rely on a CPUFeaturesAuditor visitor. This visitor keeps a list of
+//     features actually encountered so that a large block of code can be
+//     examined (either directly or through simulation), and the required
+//     features analysed later.
+//
 // Expected usage:
 //
 //     // By default, VIXL uses CPUFeatures::AArch64LegacyBaseline(), for
@@ -228,6 +239,15 @@
            Feature feature2 = kNone,
            Feature feature3 = kNone) const;
 
+  // Return the number of enabled features.
+  size_t Count() const;
+
+  // Check for equivalence.
+  bool operator==(const CPUFeatures& other) const {
+    return Has(other) && other.Has(*this);
+  }
+  bool operator!=(const CPUFeatures& other) const { return !(*this == other); }
+
   typedef CPUFeaturesConstIterator const_iterator;
 
   const_iterator begin() const;