We use the checked features in the right places

Prints a more helpful error message, saying what features have been
dropped.

Doesn't work on windows

Instead of changing how features are interpreted depending of whether
they work or not, each feature can check itself if it is supported.

We then have a function which builds a new FeatureSet from an existing
one, filtering out the features that aren't supported.

I also added a method that only returns the features that were mentioned
in the FeatureSet in the map of the results.

We normalize the features by using the existing FeatureRatio, it's just
printed differently.

We don't need to supply a list, the FeatureSet IS a List

Makes the code much cleaner.

HTTP -> SSH

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

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

Some features are about hardware, some are about software. So you need
separate classes to print data with the right types

We'll look into /usr/local/ first.

If it now works, it will be the end of years of struggle to get these
damn library.path set!

Instead of trying to manipulate tasks directly, the plugin just sets
and extra property you should have access to.

addCounter should do things the smart way, so we use that.

Had already disabled it before...

Instead of using the SyntheticBenchmarkFeaturePrinter, we can now use
the new API for printing vectors of features. It uses Experiment to get
the features and aggregate them.

SQUASH ME

Depending of the format we use, we'll print different things when
printing to CSV.

If you already obtained the cycles, no need to evaluate it again.

We print the same thing as what the Feature Printer prints

We might want the CostFeature to have the feature we aggregate, but
I used to print "cyclesInsertions", so it makes more sense to me to
constrain it to cycles.

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).

This type is the type we'll use for storing the results of an
experiment, instead of just a list of maps.

The PAPICounter class checks that the counter works on the current
machine everytime create one. That way, we don't need the list.

This can replace the PapiRunner family of classes.
It just gathers all your features nicely, in a lost less code!

Added some tests too!

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

When you create a PAPI counter, it will check that this counter is
available on the machine!

That probably means you should create too many counters, but you
probably don't need to.

BenchmarkInvocations -> TotalMethodInvocations

MethodIterationCounts -> MethodInvocations

Because we might need to iterate on them (and because the eventSet is
actually a list). We want to make sure the counters are not mixed up.

We move this to the "papicounters" package, since it uses PAPI.

Takes a specification of features and builds the PAPI eventSet you'd
need to use it.

A FeatureSet is a group of features. We want to interpret those in a
certain way.