rust: support audio

[wchargin]

Summary:
We now support TF 1.x and TF 2.x audio summaries. This includes TF 2.x
audio summaries with labels; the labels will be stripped. This means
that the audio dashboard now works under --load_fast.

Test Plan:
Unit tests should suffice. As an end-to-end test, checked the audio
dashboard against TF 2.x audio summaries both with and without labels
(i.e., of shape [k, 2] and of shape [k]), and against TF 1.x data.

wchargin-branch: rust-audio

[psybuzz]

neat use of chunks_exact_mut

[psybuzz]

(no action needed) Initially, I thought it was curious that we don't have to write mut self in the signature, but since the function takes ownership, it is implied that 'self' can be mutated. Is this understanding correct?

[wchargin]

Kind of. The mut in x: mut self is a property of the variable
binding, not the type. To demonstrate the orthogonality, consider:

let mut xs = vec![0, 1, 2];

let mut x: &mut i32 = &mut xs[0];
//  ^^^     ~~~

The first mut means that it’s legal to write x = &mut xs[1]:
reassigning to the variable binding. This is entirely up to the call
site, like const/let in JavaScript.

The second mut means that it’s legal to write *x = 0, mutating the
value behind the binding. This is a property of the type, like
ReadonlyArray/Array in TypeScript: if I give you a read-only array,
you can’t just choose to interpret it as an Array.

It can often be useful to have a mutable binding even if the value is at
an immutable reference type:

fn parse_number(mut buf: &str) -> Option<i32> {
    let mut sign = 1;
    if buf.starts_with('-') {
        sign = -1;
        buf = &buf[1..];
        //  ^^^^^^^^^^^  reassigns to `buf`, even though the underlying
        //               buffer's *contents* are immutable
    }
    Some(buf.parse::<i32>().ok()? * sign)
}

The mutability of the binding is always at the discretion of the caller,
and doesn’t affect types or APIs. The caller can change it at will:

let xs = vec![0, 1, 2];
// `xs.push(3)` is illegal here; `xs` is not `mut`

let mut ys = xs; // same value (moved, not copied); binding is now mutable
ys.push(3); // legal

let zs = ys;
// `zs.push(4)` is illegal again

The code in this PR is analogous. We bind self immutably, and we don’t
modify self. But in the Tensor clause of the match expression, we
bind tp mutably, so that we can call chunks_exact_mut.

So your claim that

since the function takes ownership, it is implied that 'self' can be mutated

is correct, in a way. It’s implied that self can be changed to a
mutable binding since the binding is always “owned” by the function.

[wchargin]

neat use of chunks_exact_mut

Yeah; chunks_exact_mut and chunks_mut (which gives you the partial
remainder of the last chunk rather than dropping it) are super cozy.
I often find myself wishing that Python’s itertools had an equivalent.
The Rust iterator API provides a lot of nice methods, similar to Java’s
streams, and often they’re just what’s wanted.