Model context as an atom?

Nobody has claimed this yet.

Crazy idea: Add more magic to the `defconsumer` macro so that the context value gets bound and passed in as a *reagent atom*.

I'm imagining it could do something like this:

```clojure

(def my-context (context/create))

(defconsumer my-component my-context
[context-state]
[:div "Current value: " @context-state])
```

Which would expand to:

```clojure
(defn my-component []
(let [context-state (r/atom (context/get-current-value-somehow my-context)]
(fn []
[:<>
[context/consumer {:context my-context}
(fn [v] (reset! context-state v)]
[:div "Current value: " @context-state]])))
```

This might solve the issue that any children written directly inside of the render function given to the `consumer` don't get reactively bound to their ratoms.

Potential problems:

1. The `consumer` is kind of an orphan in the component tree. Need to make sure this doesn't cause issues.

2. Currently, `consumer` expects that the return value of the render function is a hiccup form and calls `reagent.core/as-element` on it. Probably don't want that in this case.

3. Perf issues: if parent component of `my-component` re-renders, it might trigger a `reset!` of the context-state, which might trigger the components bound to `context-state` to re-render twice (once for the parent re-render and once for the `reset!`)

Start by tracing the defconsumer macro and the consumer implementation, including how context/create is used and how consumer handles its render function. Determine whether reactive context state can be introduced without breaking the component tree or as-element behavior, and resolve the duplicate re-render concern before defining acceptance criteria.

Written by the indexing model from the issue text.