The user may declare parameters by doing, at the top level:
```cpp
    NONIUS_PARAM(name, <default_value>);
```

This declares a parameter.  Parameters can be then passed to the `main`
program by passing arguments of the form:
```
    -p <name>:<value>
```

The parameters have to be accessed from the chronometer.  Since
parameters can have any type and are string-addressed, they can only be
finally parsed or unboxed and looked up in the benchmark.  To stop users
from mistakenly adding that cost to their tests, they are forced to
extract the parameters before, from the chronometer.  Of course they can
cheat by capturing the chronometer, but the documentation should guide
users in the right direction.  A good example:
```
NONIUS_BENCHMARK("push_back vector", [](nonius::chronometer meter)
{
    auto n = meter.param("size");
    auto storage = std::vector<std::vector<char>>(meter.runs());
    meter.measure([&](int i) {
        auto& x = storage[i];
        for (auto j = 0; j < n; ++j)
            x.push_back(static_cast<char>(j));
    });
})
```

The parameter name is now required to be a string already.  There is no
fundamental reason why parameter names should be limited to identifier
names rules.  The fact that `NONIUS_DETAIL_UNIQUE_NAME` already exists
is convenient here.

This changes syntax for the user from:
```cpp
    NONIUS_PARAM(name, 42);
```

To:
```cpp
    NONIUS_PARAM("name", 42)
```

Note the semicolon is not needed anymore either.

The syntax is:
```
    -p <name>:<oper>:<init>:<delta>:<steps>
```

This tells that the benchmark should be run with `<steps>` different
values for parameter `<name>`.  Each value is computed as:
```
    next = last <oper> deta
```

Where `<oper>` may be `+` or `*` as for testing with linear or
exponential increments (the later is useful when checking logarithmic
algorithms or subtle non-linearities in the "constant factors" of an
implementation).

The old code was convoluted, with too many assertions and implicit
assumptions.  Instead of generating all the samples that we want to try
in the argument parsing, we delay this logic to a more appropriate place
later, without loss of information.

The only drawback of the new configuration representation is that it may
be less flexible, as the previous one allowed to easily add passing
explicitly all the various parmeters to try.  We can, though, easily add
this later by adding more options to the configuration.

The functions `go_benchmark` and `go_param` where extracted, since the
function had grown too big to my taste after the parameter running logic
had been introduced.

Also, the main loop has been simplified to avoid the need to `continue`,
which is more structured IMHO.

We always store parameters generically as `std::string`.  The user
implicitly suggests a concrete value type with the type of the default
value of the parameter.  We use that type when we need to do arithmetic
on the parameter and also when checking that it parses correctly when
passed from the command line.  We do this by casting the strings back to
the original `T` using the `param_spec` interface.

This might seem overkill.  Another approach could be to type erase the
concrete values once intially parsed from the command line, using a
`boost::any`-like type erasure class.  However that approach is less
flexible, because it requires the user to provide the specific concrete
type when calling `chronometer::param<T>()` and just a mistake in
signedness or whatever could be fatal.  Just parsing everything into and
back from strings is more forgiving on numeric types, which is the most
common case.

This commit adds a new `example7` that where using ranged parameter
would not work correctly previously.

This commit refactors a lot of the code added in this branch. The
original goal was to reverse how `go()` runs through various
parameter values.  Before it did like:

    for each benchmark
        for each parameter
            run-benchmark()

Now it is more like

    for each parameter
        for each benchmark
            run-benchmark()

This new structure should make writing reporters easier, since it better
fits how the data could be presented to the user in meaningful ways --
we'll see more of this in later commits.

A couple of more refactorings has sneaked in this commit:

- `param_map` and `param_registry` etc. are not in `detail::` anymore.
  This is to better fit other parts of the library (e.g. benchmark,
  reporter) that are not in `detail` and arguably at the same level of
  abstraction from the user API POV.

- A couple of functions now have a more "data driven" approach, trying
  to reuse previously computed data more often, as to improve the
  overall performance.

The old API for benchmarks that have fixtures is like this:
```cpp
NONIUS_BENCHMARK([] (nonius::chronometer meter){
  // setup code
  m.measure([&] {
      // benchmark code
  })
});
```

That API is nice, but since it has to assume that the benchmark code can
always mutate the setup, the setup can not be reused across samples.
This is ok in general, but for benchmarks that have expensive setups
relative to their measured time, time might be wasted uneedesly.

Our alternative syntax is like:
```cpp
NONIUS_BENCHMARK([] (nonius::parameters meter){
  // immutable setup code
  return [=] {
      // benchmark code
  }
});
```

Or even further:
```cpp
NONIUS_BENCHMARK([] (nonius::parameters params){
  // immutable setup code
  return [=] (nonius::chronometer meter) {
      // mutable setup code
      meter.measure([&] {
          // benchmark code
      })
  }
});
```

The idea is that when the benchmark function can take a `parameters`
argument, it is assumed to be a factory that then returns the actual
benchmark function.  This factory function is called *only once* for a
given set of parameters (in `prepare(...)`) and the resulting benchmark
function is kept in the `execution_plan` and reused for collecting all
the samples.

Furthermore, this syntax may be more intuitive for people that need
parameters, but do not need a chronometer.

When trying to figure out how long to run a test to get a meaningful
value, we may fall into an infinite loop when the whole benchmark has
been optimized away.  We now try to detect this case by hard-limiting
the number of iterations we do in the loop.

This partly solves libnonius#52.  A complete solution involves properly
deoptimizing the return value of the benchmark function.

The exception message would get mixed together with other lines of
messages creating confusion.

Now all the logic of deciding which parameters to execute is contained
in `generate_params`.  We removed the "feature" that `parameters` looks
up default values.  This way the code we remove dependencies on global
state, and make the feature more testable.  `generate_params` now merges
the default values with the fixed values with the values generated for a
parameter run.

The command line parser would only look at the first instance of an
argument.  This would prevent us from passing multiple parameters to the
benchmark runner. Examples that did not work but now do work:
```
    # Would only set string=foo, discarding size
    example6 -p string:foo -p size:42
```
```
    # Would only run size:42,52,..., discarding string
    example6 -p size:+:42:10:10 -p string:foo
```