mock: improve ergonomics when an ExpectedSpan is needed

[hds]

Motivation

Many of the methods on MockCollector take an ExpectedSpan. This
often requires significant boilerplate. For example, to expect that a
span with a specific name enters and then exits, the following code is
needed:

let span = expect::span().named("span name");

let (collector, handle) = collector::mock()
    .enter(span.clone())
    .exit(span)
    .run_with_handle();

Solution

In order to make using tracing-mock more ergonomic and also more
compact, the MockCollector and MockSubscriber methods that previous
took an ExpectedSpan, are now generic over Into<ExpectedSpan>.

There are currently 3 implementations of From for ExpectedSpan which
allow the following shorthand uses:

T: Into<String> - an ExpectedSpan will be created that expects to
have a name specified by T.

let (collector, handle) = collector::mock()
    .enter("span name")
    .exit("span name")
    .run_with_handle();

&ExpectedId - an ExpectedSpan will be created that expects to have
the expected Id. A reference is taken and cloned internally because the
caller always needs to use an ExpectedId in at least 2 calls to the
mock collector/subscriber.

let id = expect::id();

let (collector, handle) = collector::mock()
    .new_span(&id)
    .enter(&id)
    .run_with_handle();

&ExpectedSpan - The expected span is taken by reference and cloned.

let span = expect::span().named("span name");

let (collector, handle) = collector::mock()
    .enter(&span)
    .exit(&span)
    .run_with_handle();

In Rust, taking a reference to an object and immediately cloning it is
an anti-pattern. It is considered better to force the user to clone
outside the API to make the cloning explict.

However, in the case of a testing framework, it seems reasonable to
prefer a more concise API, rather than having it more explicit.

To reduce the size of this PR and to avoid unnecessary churn in other
crates, the tests within the tracing repo which use tracing-mock will
not be updated to use the new Into<ExpectedSpan> capabilities. The new
API is backwards compatible and those tests can remain as they are.