ENH: Use get_rst_label for figure files

prevents problems when names contain e.g. [0, 0]
NF: support running benchmarks across multiple branches. TODO: storing-in-db/plotting branches

It also involved internal RFing for GitRepo to store commits information in
a single DataFrame instead of multiple Series.  DataFrame is indexed by sha
and only where necessary sorting/selection of revisions is done based on
timestamps
ENH: allow to produce overlayed plots per each branch
OPT: use --date=rfc2822 for git log, and parse date using rfc822 module

Should provide 80-90% speed up for parsing dates, thus quickening up
initial git log analysis considerably on big repositories
BF: store information about rev->branches regardless of running benchmarks for rev or not

our specific case was that we haven't traced branches before and now none is marked for master

but in general, revision might get marked for a new branch we haven't benchmarked before,
so better update all the time
BF: do not try to plot whenever there is no revisions for a branch + log msgs
BF: ensure xlims to cover dates for all branches (+downgrade a log msg)
ENH: enclose compile, exec, and timer.repeat in try/except to provide details on the original src as warnings
ENH: do not bottom y axis to 0 unless yhi > 3 + avoid crashing if nothing was plotted
ENH: list benchmarks for the module sorted by its str (i.e. by name) + prevent some crashes in obscure cases
BF: was checking either to report results solely on the last res (not all_res)
ENH: timeit -- threshold at 0.2 ms not 0.1 for determining number of runs

that is what ipython has, that is what comment has and it sounds as reasonable.
Otherwise I believe it contributes to instability of some performance assesments
in numpy-vbench
ENH: even if bm runs > 0.2 ms, run at least 3 times
ENH: magic_timeit -- waste less time to estimate number of runs + aim for target timing

With original implementation number of runs to do can vary 10-fold from time to time.
Moreover it might take up to 2 sec only to estimate how many runs is needed before even
running any benchmarks.

This implementation grows number by powers of 2 instead of 10, which minimizes the spread
of 'number' any given benchmark might do across different runs.  Also it estimates power to bring
to instead of going one at a time which is not much but helps a bit + if it estimates that
after last increment it should 'meet' expected timing it breaks loop as well without
next timing.

This way with default options (target_timing=0.3, 3 repeats) it completes benchmarks usually
within 2 seconds.
NF: some metrics to report (vmem, pid) and control of logging from the environment

needed to troubleshoot extensive memory use while running benchmarks... so now it should be possible

VBENCH_LOGMETRICS=vmem,pid VBENCH_LOGLEVEL=DEBUG PYTHONPATH=$PWD nosetests -s -v vbench/tests/vbenchtest
ENH: vb_run_benchmarks -- use vbench's logging (if avail) and report time it took for a benchmark at debug level
Limit maximum number to loop to 100000

if we need that many iterations, most probably run time is already
bound by the loop itself
ENH: by default no repeat or number specified -- deduce both targetting .5sec target timing

having only 3 repeats by default to take min of adds to variance.
Deduce both repeat and number (if none specified -- sqrt of total number of runs needed
to meet target timing).  It seems also to allow reduce 'looping' overhead thus
getting lower timing estimates for relatively fast statements
TST: for preceeding changes to magic_timeit
ENH: db -- get/delete benchmarks results for a revision