Some tests failed because the way we handle counters wasn't correct.

Christoph implemented some optimizations to avoid stopping counters when
it's not needed

I updated the client code to use the new API.

There are a lot of strings which are actually the same string, except
the JVM stores the same data in two different objects. I used intern()
to try to make sure it's the same objects that is used if we've already
seen that string before.

If we used a "Tracer" collection, the name would end up in the printed
output. We implement a function that removes that, so that it looks like
we used one of the normal collections.

We don't need to clean the eventSets if we used the same set at the
previous Spec

We can actually handle more than 2 counters! So we make sure we do

We just de-activate the counters that are not avaiable.

Useful for testing

I removed the parameters numRuns and counters from the constructor of
PapiRunner, this parameter is passed in the specs instead and as a
parameter of the specific functions that need it.

This is so I can pass a PapiRunner without the number of runs to an
Experiment and run it. Otherwise you might have to check the papiRunner
has the same number of runs than the Experiment...

PapiBenchmarkAnalyzer.RunSpec doesn't take
the number of iterations as a parameter anymore, as that's a parameter
of the runner itself (it was always the same value used anyway).

Sometimes we only trace the default counters, and then the tracer might
now know we want to trace. So we set the flag.

We used PAPI counters before, and it's true these are the most relevant,
but it makes sense to make this more general.

We use the PAPICounter type for specifying list of counters and stuff,
instead of the map of strings. This makes the code _MUCH BETTER_.

Previously, we didn't add the operationType to the key at all. Now the
map is a full function, but it just reports 0 cycles spent if there
weren't any in the benchmark.

We removed the need of a StopWatchRunner by making sure we only run the
benchmark once, even for getting the number of cycles per operation
type.

The papiRunner class now gathers all the counters in one single run.
For that, we need to gather a limited number of counters: PAPI_TOT_CYC +
PAPI_TOT_INS + max 2 counters.

Because we don't do any aggregation either, I needed to change the
functions so they return a list of values for each iteration.

We have a map of cycles per operation type, and we use in a function
that will run specifications, aggregate the number of cycles per each
method of that type, and return a list of triplets (run#, opType,
cycles).

We extracted one for running one iteration of a benchmark and one for
running many iterations.

The first thing we were doing with the stream was converting to string anyway.

Not needed, since we re-implemented runSpec directly.

Works similarly to how runSpec runs for a regular PapiRunner.

Updated smrt.jar because there are some methods we needed to reset the
tracer and set it's counters dynamically.

We run the benchmarks, get some counters, and aggregate them.

What's not finished is that we don't get the median over many runs,

nor do we gather counters yet.

This PapiTracerRunner shares similarities with PapiRunner, so we make
an interface that contains stuff that's common to the two classes.