Too many PMC implementations

[Maxime Villard <max%m00nbsd.net@localhost>]

Right now we have three (or more?) different implementations for Performance
Monitoring Counters:

 * PMC: this one is MI. It is used only on one ARM model (xscale I think).
   There used to be an x86 code for it, but it was broken, and I removed it.
   The implementation comes with libpmc, a library we provide. The code
   hasn't moved these last 15 years. I don't like this implementation, it is
   really invasive (see the numerous pmc.h files that are all empty).

 * X86PMC: this one is MD, and only available for x86. I wrote it myself.
   The code is small (x86/pmc.c), and functional. The PMCs are system-wide,
   and retrieved on a per-cpu basis. But this implementation does not
   support tracking, that is, we get numbers (about the cache misses for
   example), but we don't know where they happened.

 * TPROF: this one is MI, but only x86 support is present. TPROF provides
   the backend needed to support tracking: via a device, that userland can
   read from, in order to absorb the event samples produced by the kernel.
   The backend is pretty good, but the frontend (where the user chooses
   which PMC etc) is inexistent - the CPU/event detection is not there
   either. The backend is MI (/dev/tprof/tprof.c), and can be used on other
   architectures. The module already exists to dynamically modload.

I think it would be good to:

 * Remove PMC entirely. Then remove libpmc too.

 * Merge X86PMC into the x86 part of TPROF. That is to say, into
   x86/tprof_*. Then remove X86PMC.

 * Later, maybe, someone will want to add other architectures in TPROF, like
   all the recent ARMs.

Maxime