Current updatePriority is tracked in the reconciler. `flushSync` is going to be implemented reconciler agnostic soon and we need to move the tracking of this state to the renderer and out of reconciler. This change implements new renderer bin
dings for getCurrentUpdatePriority and setCurrentUpdatePriority.

I was originally going to have the getter also do the event priority defaulting using window.event so we eliminate getCur
rentEventPriority but this makes all the callsites where we store the true current updatePriority on the stack harder to
work with so for now they remain separate.

I also moved runWithPriority to the renderer since it really belongs whereever the state is being managed and it is only
currently exposed in the DOM renderer.

…ticularly meaningful in this change this demonstrates how we can use this to implement flushSync in a way that does not require the reconciler being loaded so it can be used in the top-level entrypoint without pulling in the reconciler

…when you are reading a raw value and when you are getting a resolved value. This allows requestUpdateLane to do a single call into the renderer to get the update priority while still making a reasonable stack based updating of update priorities ergonomic. I had to expose a `peekCurrentUpdatePriority` to satisfy startTransition which needs to set a new priority only if the current one is too low. I tried to stay away from get/set naming to avoid potential issues with whether you are reading the raw value or the derived one that considers window.event