Challenge 3: Shared Mutable Vec via Rc<RefCell<Vec<i32>>> — Possible Solution
====================================================================

use std::rc::Rc;
use std::cell::RefCell;

fn main() {
    let shared = Rc::new(RefCell::new(Vec::new()));

    let owner_a = Rc::clone(&shared);
    let owner_b = Rc::clone(&shared);
    let owner_c = Rc::clone(&shared);

    owner_a.borrow_mut().push(10);
    owner_b.borrow_mut().push(20);

    println!("{:?}", owner_c.borrow()); // [10, 20]
}

WHY THIS WORKS AS AN ANSWER
------------------------------
Rc::clone is used three times to produce three separate HANDLES
(owner_a, owner_b, owner_c) that all point at the exact same
underlying RefCell<Vec<i32>> — per this chapter's Rc explanation,
cloning an Rc never duplicates the actual data, only the reference-
counted pointer to it.

owner_a.borrow_mut().push(10) and owner_b.borrow_mut().push(20) each
obtain a temporary mutable borrow of the SHARED Vec through RefCell's
interior mutability (Chapter 4's core mechanism) — despite owner_a and
owner_b being separate variables, they're mutating the identical
underlying vector, not independent copies. Each borrow_mut() call is
scoped narrowly to just the .push(...) call, so the two mutations
don't overlap in time and don't trigger RefCell's runtime borrow-
conflict panic.

Printing owner_c.borrow() — a THIRD, independent handle that never
performed either push itself — still shows both values ([10, 20]),
concretely proving all three owners are genuinely sharing one single
piece of data rather than each holding their own separate vector. This
is exactly the "multiple owners, each able to mutate the shared data"
behavior this chapter's Rc<RefCell<T>> section described.