Don't force treating implementations like parameters

```
Here's how we handle multiple implementations today:

http://code.google.com/p/caliper/source/browse/trunk/src/examples/SetContai
nsBenchmark.java?spec=svn91&r=91#41

@Param private Impl impl;
public enum Impl {
Hash {
@Override Set create(Collection contents) {
return new HashSet(contents);
}
},
LinkedHash {
@Override Set create(Collection contents) {
return new LinkedHashSet(contents);
}
},
. . .

For starters, it's cumbersome. Also, according to the issue I'm about to
file next :), it may make sense for us to run all the various parameter
combinations for a single implementation in just one VM invocation, but
this would not make sense for implementation.

What if, instead, we allow for this:

public void setUpFoo() { ... }
public int timeFoo() { ... }
public void setUpBar() { ... }
public int timeBar() { ... }

In fact, sometimes timeFoo() and timeBar() would be identical, so we could
even support

public void setUpFoo() { ... }
public void setUpBar() { ... }

public int time() { ... }

This might get confusing, but I think the behavior could be fairly simply
defined in terms of the method names. The benchmarks to run are the union
of the names that appear after "setUp" and those that appear after "time";
for each, run "setUpName" if it exists, else "setUp"; then run "timeName"
if it exists, else "time".

```

Original issue reported on code.google.com by `kevinb@google.com` on 22 Jan 2010 at 10:45