Store artifact sizes into the database

[Kobzol]

It would be really nice to track the size of generated artifacts (especially the size of binaries) over time. There are a lot of things that we could do in this direction, but probably the simplest one to begin with is to generate stats corresponding to the artifact sizes that are produced by the self profiler.

With this small change, we can start tracking artifact sizes for the currently existing benchmarks. This is just a small first step, of course, but it should already provide us with interesting data.

I used the size: prefix for the stats, to differentiate these values from the existing metrics. Maybe we could add some unified prefix to the compile time metrics? Later we can add yet another prefix for metrics gathered from compiled binaries.

Related issue: #145

[nnethercote]

This is timely, because I'm looking at code generated for derive and shrinking binary sizes is one goal.

I'd never looked at the artifact sizes being recorded by self-profiling. Quite a range, and different depending on the scenario, interesting. It would be nice to have the stuff reported by size (.text, .data, .bss, total size), would that be difficult?

[Kobzol]

It would be nice to have the stuff reported by size (.text, .data, .bss, total size), would that be difficult?

That would indeed be nice, but it delves into the territory of using special gathering/visualisation for size data. I could add code that would measure the text/data/bss sections individually, but this would create yet more metrics. Currently, this PR adds about 6-7 new size: metrics and the metric list in the compare page is getting a bit too unwieldy I think. Maybe we should somehow rethink the UI or create some separate categories for compile time/size/(runtime) metrics to distinguish these things better.

[Kobzol]

I rebased this over #1338 and added new explicit size: metrics.