Adds overload to restrict dispatch access to the view function.

[noheltcj]

This looks good to me. Tested the ergonomics of the change; very much improves the experience. Of course there are pros/cons to deprecating the option to have dispatch in the render function. Outside of situations where users wrap the runtime to synchronously obtain the first set of props, this new method has no known drawbacks. But, in cases where synchronous initial props are desired, having the dispatch be potentially nullable is useful (or at least having the choice to do so is useful) to avoid essentially rebuilding the runtime or practically doing so in a wrapper. For these users to keep the props-only render function pattern, they must move the decision to handle null or crash to the wrapper or build a custom mechanism over Oolong instead of simply providing a nullable dispatch and checking that when a props-provided event would be triggered.

Outside of that edge case, the new API improves ergonomics and should be the recommended way to use Oolong in my opinion.

[dallasgutauckis]

I think this should also include changes to the core-concepts.md file to remove dispatch from props function examples and move that into the view implementation