Challenge 3: Explaining Function Coloring — Possible Solution
====================================================================

The "function coloring" problem refers to the fact that async fn and
ordinary ("sync") functions are effectively two different KINDS of
function that don't mix freely — often described as functions having
one of two "colors."

Using this chapter's greet(name: &str) -> String example (declared
async fn): calling greet("Ada") from ORDINARY, non-async code does
compile — but it only produces a Future value, not the actual String
result, since (per this chapter) an async fn's body never runs until
.await drives it. To actually GET the String, .await is required — but
.await can ONLY be used inside another async fn or async block. This
creates a real, structural constraint: an ordinary, non-async function
genuinely CANNOT call .await on greet's Future to obtain its result
directly, because doing so would require the ordinary function itself
to somehow pause and yield control back to a runtime — a capability
only async functions have, since being "pausable" is precisely what
the async/await machinery adds to a function.

WHY THIS IS A REAL PROBLEM, NOT JUST A SYNTAX QUIRK: it means that
once ANY function somewhere in a call chain needs to call an async
function and actually use its result, EVERY function further up that
call chain typically also needs to become async itself, all the way up
to wherever a runtime (like #[tokio::main]) is actually available to
drive things — a change that can ripple through a lot of otherwise
unrelated code, purely because of one function's "color." This is
exactly the well-known critique of async/await as a general language
feature (not unique to Rust) that this chapter named directly, and
it's precisely the friction Go's goroutines avoid entirely by never
requiring a function to be specially marked or "colored" just to be
used concurrently.