tracing: add Span::or_current to help with efficient propagation

[hawkw]

This adds a new Span::or_current method that returns the span it's
called on, if that span is enabled, or the current span if that span
is not enabled.

This should provide a more efficient alternative to writing code like

tokio::spawn(
    future
        .instrument(some_span)
        .in_current_span()
);

since it doesn't wrap the future in two different spans which are
(potentially) both entered on polls. It's also a little more concise
to write, which (hopefully) will encourage people to use it instead
of the less efficient alternative.

Span::or_current may be useful in other cases as well.

[davidbarsky]

Two notes:

1. I feel like this the necessity of this combinator illustrates why don't really like levels in spans.
2. When backporting, be sure to swap out "collector" for "subscriber"!

[davidbarsky]

Suggested change

	/// [async tasks]. For example, consider the following:
	/// [async tasks]. Consider the following:

[hawkw]

@davidbarsky

1. I feel like this the necessity of this combinator illustrates why don't really like levels in spans.

Sure...but it's also not exclusively due to span levels. Even if spans don't have levels, you could still have a similar scenario if you're enabling spans based on their targets. For example, a parent span might be propagated by a child in a module you disable by target.

It's a consequence of any kind of filtering of spans, not just by level. Although, I will admit that it's easier to end up in this situation with level-based filtering, I think that's more a consequence of most people doing level-based filtering.

[hawkw]

@davidbarsky couple quick questions before I merge this:

1. As a follow-up, what do you think about adding a method to Instrument that automatically calls or_current...maybe Instrument::propagate? Alternatively, we could change instrument to always call .or_current(), and add a separate combinator to Instrument that's "this span, or nothing"...but I'm a little more leery of changing the current behavior, especially in 0.1.
2. Do you think the docs ordering makes sense? i put the example with threads before the example with async tasks, but I think more users will probably be spawning tasks than threads. However, I thought the thread based example was a little more straightforward since it uses enter rather than Instrument, and I thought it made more sense to introduce the basic behavior of or_current without also having to talk about the Instrument combinator...