Reduce bandwidth with scope_ids

[emilk]

Problem

Currently each profile scope sends an id and a location.

The id is either the function name (for profile_function!()) or a user-specified static string (profile_scope!("calc_normals")).
The location is the file name (or file path and file number, when #165 is merged).

There is also the data field, which is e.g. the mesh name in fn load_mesh(name: &str) { profile_function!(mesh_name); … }. This could change on each invocation, while the id and location does not.

All these fields are send on each invocation of the profiling macro. This can become quite a lot of bytes if the id and/or location is long (and they become longer in #165).

The compressor mitigates this problem, but at the cost of CPU time.

Solution

Let's introduce:

struct ScopeInfo {
    /// Scope name, or function name (previously called "id")
    name: String,

    /// Path to the file containing the profiling macro
    file: String,

    /// The line number containing the profiling
    line_nr: uint
}

/// A unique id for each scope and `ScopeInfo`.
pub struct ScopeId(u32);

The first time a profiling scope is executed it is assigned a unique ScopeId. It sends its ScopeInfo as a special message on the data stream.
After that, and on each subsequent call, it sends only its scope id and, time stamp, and additional data (e.g. mesh name, which can change each invocation).

This means the scope info is only sent once, saving bandwidth on each repeat invocation.
This would also allow us to send more info for each scope, e.g. the full file path instead of just a short version of it.

This requires a stateful receiver which keeps a lookup table of the scopes. If the ScopeId is just an incremental counter, that lookup is as simple as Vec<ScopeInfo> (which will work as long as we're only looking at profiling scopes from one process at a time).

[repi]

@NiklasNummelin and I've talked a bunch about doing exactly this, think it is the right approach and highly important as the overhead of writing redundant strings for every invocation of a profiler timer really does add up

[TimonPost]

Closed by #169