fixes #1202. sort of.

* add g++ to sanitizer buildbots

* add compiler to sanitizer build name

* spell g++ correctly. look, it's early, ok?

* only set libcxx if we're using clang

Fixes #1196

repetition_indices is populated with size_t values, so typing it
accordingly.

* Use C++11 atomic_signal_fence for ClobberMemory

* include

* Conditionally using std::atomic_signal_fence when C++11 is available

* Don't link pthread on QNX

On QNX, pthread is part of libc [1]. There's no separate pthread library
to link.

[1] https://www.qnx.com/developers/docs/7.1/index.html#com.qnx.doc.neutrino.lib_ref/topic/p/pthread_create.html

* Explain that QNX doesn't have pthread lib

This appears to be the source of unclean termination of the test on some
versions of python related to object dereferencing.

This avoids clashes with other libraries that might define the same flags.

* Add missing trailing commas

Fixes #1181

* Better trailing commas

This can be used together with ArgsProduct() to allow multiple ranges
with different multipliers and mixing dense and sparse ranges.

Example:
BENCHMARK(MyTest)->ArgsProduct({
  CreateRange(0, 1024, /*multi=*/32),
  CreateRange(0, 100, /*multi=*/4),
  CreateDenseRange(0, 4, /*step=*/1)
});

Co-authored-by: Jen-yee Hong <pcmantw@google.com>

Some downstream projects (e.g. V8) treat warnings as errors and cannot roll
the latest changes.

Fixes https://github.com/google/benchmark/issues/1172

* Use modern clang/libc++ for sanitizers

* update ubuntu

* new llvm builds differently

* clang, not clang-3.8

* just build what we need

* Enable various sanitizer builds in github actions

* try with off the shelf versions

* nope

* specific version?

* rats

* oops

* remove msan for now

* reorder so env is set before building libc++

Inspired by the original implementation by Hai Huang @haih-g
from https://github.com/google/benchmark/pull/1105.

The original implementation had design deficiencies that
weren't really addressable without redesign, so it was reverted.

In essence, the original implementation consisted of two separateable parts:
* reducing the amount time each repetition is run for, and symmetrically increasing repetition count
* running the repetitions in random order

While it worked fine for the usual case, it broke down when user would specify repetitions
(it would completely ignore that request), or specified per-repetition min time (while it would
still adjust the repetition count, it would not adjust the per-repetition time,
leading to much greater run times)

Here, like i was originally suggesting in the original review, i'm separating the features,
and only dealing with a single one - running repetitions in random order.

Now that the runs/repetitions are no longer in-order, the tooling may wish to sort the output,
and indeed `compare.py` has been updated to do that: #1168.

* Fix leak in test, and provide path to remove leak from library

* make doc change

Currently the lifetime of a single BenchmarkRunner is constrained
to a RunBenchmark(), but that will have to change for interleaved
benchmark execution, because we'll need to keep it around to not
forget how much repetitions of an instance we've done.

Based on original implementation by Hai Huang @haih-g in
https://github.com/google/benchmark/pull/1105

Currently, the tooling just keeps the whatever benchmark order
that was present, and this is fine nowadays, but once the benchmarks
will be optionally run interleaved, that will be rather suboptimal.

So, now that i have introduced family index and per-family instance index,
we can define an order for the benchmarks, and sort them accordingly.

There is a caveat with aggregates, we assume that they are in-order,
and hopefully we won't mess that order up..

While the current variant works, it assumes that all the instances of
a single family will be run together, with nothing inbetween them.
Naturally, that won't work once the runs may be interleaved.

Much like it makes sense to enumerate all the families,
it makes sense to enumerate stuff within families.
Alternatively, we could have a global instance index,
but i'm not sure why that would be better.

This will be useful when the benchmarks are run not in order,
for the tools to sort the results properly.

It may be useful for those wishing to further post-process JSON results,
but it is mainly geared towards better support for run interleaving,
where results from the same family may not be close-by in the JSON.

While we won't be able to do much about that for outputs,
the tools can and perhaps should reorder the results to that
at least in their output they are in proper order, not run order.

Note that this only counts the families that were filtered-in,
so if e.g. there were three families, and we filtered-out
the second one, the two families (which were first and third)
will have family indexes 0 and 1.

It takes the whole total new capacity, not the increase.

Ensure that we print repetition count even when it was specified via flag `--benchmark_repetitions=`

This reverts commit a6a738c1.

* Fix argument order in StrSplit

* Update AUTHORS, CONTRIBUTORS

It seems that by setting the /topic in freenode #googlebenchmark to point to libera I have angered the powers that be and we've been locked out of the channel. Libera it is then.

';' after method definition was removed.
Also, pedantic flag is now uncommented in CMakeList.txt.

* cmake: fix handling the case where `git describe` fails

* cmake: fix version recorded in releases

If downloaded as a tarball release, there will be no info from git
to determine the release, so it ends up v0.0.0. If that's the case,
we'll now use the release specified in the project() command,
which needs to be updated for each new release.

* cmake: add `--tags` to `git describe`

That way, lightweight tags will also be taken into account, which should
never hurt, but it'll help in cases where, for some mysterious reason or
other, annotated tags don't make it into a clone.

* update releasing.md