Proposal 2 changes to report generator
  1) Changes to opreport
     - Control whether or not anonymous samples included in reports.
     - Does not need to know JIT mapping data format.
     - Will need to invoke a data handler(bfd like).
  2) Anonymous mapping data must be maintained by tgid.
  3) Anonymous mapping data is not owned by OProfile. As such, it is the
     user's responsibility to delete it when no longer needed. opcontrol --reset
     will not remove any JIT mapping data (anon.tgid files) from the
     /tmp directory.

Changes to opreport
  1) Add option --anon-samples
     This option allows including anonymous samples "bucket" in reports.
     Default is to not include anonymous samples in reports.
  2) Add option --anon-handler=NAME
     This option allows an anonymous sample handler to "register"
     with opreport. The handler is implemented in libNAME.so and
     conforms to a well defined interface. If the handler can handle
     anonymous samples for a particular tgid, opreport calls it
     to do all symbol/line resolution for all anonymous samples
     on the tgid.
     If the scenario to be profiled involves more than one type of JIT
     this option can be repeated, providing a different NAME for each
     of the anonymous sample handlers. As an alternative, NAME can be
     a comma delimited list of handler names.
     This option implies --anon-samples.

Anonymous handler
  1) Handler is responsible for understanding JIT mapping data format.
  2) Implements methods required by op_bfd() class.
  3) Must implement initialization function which is invoked by opreport
     at startup to determine if this handler can handle anonymous samples
     from a given tgid.
     - If handler accepts responsibility for JIT mapping data then
       it takes over responsibility for handling all symbol resolution of
       anonymous samples on the tgid and must be called by opreport for
       the given anonymous SFILE.

As an alternative, op_bfd could be sub-classed to handle this work.

  * Stale mapping files owned by the application are erased.
  * JIT writes mapping data to /tmp/anon.tgid file in whatever format it wants.
  * Daemon/profiling session can start before or after the JIT starts.
  * As profiling session progresses the daemon is logging all anonymous
    samples for tgid in /var/lib/oprofile/samples/current/.../tmp/anon.tgid/SFILE
  * User requests a report: opreport --anon-handler=xyz -l ...
    - opreport loads libxyz.so
    - opreport generates list of sample files to include in the profile.
    - When it comes across an anonymous SFILE it invokes a predefined function
      in libxyz.so.
      - If the handler understands the JIT mapping data in /tmp/anon.tgid
        it returns true and opreport associates the handler to the particular SFILE.
        All bfd-like functionality should is sent to the handler.
      - If the handler does not understand the JIT mapping data
        it returns false and opreport handles anonymous samples as it sees fit.
  * From this point on processing continues as it does today.

  1) No additional overhead to daemon.
  2) OProfile does not have to understand/communicate with the JITs.
  3) Works with any JIT (java, C#) and with multiple, simultaneous JITs.
  4) Works whether the JIT is started before or after the daemon.
  5) Isolates OProfile from needing to know JIT mapping data format. Each JIT
     provider is free to emit any mapping data it desires and must also
     provide a handler if they want their JIT samples resolved by OProfile.
     This does not preclude OProfile from providing some type of basic support
     for common JITs or common "map" file.

  1) Must define a stable bfd-like interface to opreport.
  2) Hole for re-using memory during re-jitting is not closed, but
     can be closed if the JIT does not re-use memory during re-jitting.
  3) Hardcoded location of JIT mapping data.
  4) Increased opreport complexity.
  5) There may be "packaging" issues (ex. are handlers shipped with OProfile?)