Switch self profile to use HW counters instead of walltime

[Kobzol]

This PR changes the gathered self profile to use instructions as a metric, instead of wall time. There are some problems with this:

1. This PR simply switches the interpretation of the data to instructions. However, old artifacts will have values stored in the DB as walltime. We could record the metric (instructions/walltime) in the DB, so that we show e.g. the correct units on the detailed query page table, but this does not change the fact that there will be some pairs of artifacts where one side will have walltime, and the other instructions, and these will be basically uncomparable.

2. Instructions will be added together for all threads, which might be a bit misleading where parallelism is used.

Fixes: #1345

[Mark-Simulacrum]

I think this is broadly reasonable - I'm not too worried about the N commits that happen in the transit time, but maybe we can temporarily add a note: message to the HTML noting that? I don't think we have easy ways of tying that back to the deployed version of rustc-perf (though I seem to recall the information being persisted into the DB), so it would just be unconditional.

Adding together across threads also seems like best we can do and is already done for the general view.

[Kobzol]

I added the note to the detailed query page and added more documentation about this to the code. I also changed the formatting of values in the self profile table.

[Kobzol]

I tried locally that combining perf stat -e instructions and measureme using instructions doesn't seem to affect the results (I'm not sure if it's OK in general to "nest" PMU counter recording).

@Mark-Simulacrum I don't have any more ideas on how to test this further locally. I guess that we'll just have to merge it and see what happens :) Feel free to do that.

[bjorn3]

https://perf.wiki.kernel.org/index.php/Tutorial

Furthermore, the perf_events interface allows multiple tools to measure the same thread or CPU at the same time.

[Kobzol]

Yeah it definitely seems like it's supported, I just wanted to be sure that when I measure the same event (instructions) twice, it won't take two counter slots (to avoid possible multiplexing).

Events are currently managed in round-robin fashion. Therefore each event will eventually get a chance to run. If there are N counters, then up to the first N events on the round-robin list are programmed into the PMU. In certain situations it may be less than that because some events may not be measured together or they compete for the same counter. Furthermore, the perf_events interface allows multiple tools to measure the same thread or CPU at the same time. Each event is added to the same round-robin list. There is no guarantee that all events of a tool are stored sequentially in the list.

It's not clear to me whether this (counter sharing/multiplexing) can happen when two processes measure the exact same event.