Schema Composition: cleanup on initial PoC decisions

Reconsider/address decisions made with initial PoC. Decide which is feasible, and the timeline:
- [ ] We need to add increased integration between the LSP layer and the UI code so that errors that occur can be communicated bi-directionally.
* current behaviors which we ideally can fix with the middleware layer:
- [ ] First time schema composition is turned on after page load occurs there is a hardcoded 3 second delay to prevent race conditions.
- [ ] Race conditions can occur when a user clicks too many elements within Schema Browser too quickly.
- [x] Any general error occurring within the LSP will desynchronize it from the UI.
- [x] Page reload, and re-syncing, can cause reinitialize the composition block with many additional filters -- which requires coordination over many request/response loops.
* https://github.com/influxdata/ui/issues/5622
- [x] When a composition block is many lines, and the user does something which changes the line size too much -- the replacement text (applyEdit from the LSP) is not the right size.
* https://github.com/influxdata/flux-lsp/issues/574.
- [ ] “Flux Sync’ is a One Time One way process.
- [ ] We want to add bi-directional capability. I.e. the ability to recreate the schema browser state from an existing query state.
- [ ] We want to add support for multiple schema composition blocks with the caveat that only one block may be active in the sync functionality at one time.
- [x] We did not yet implement the default query text comment on page load which was included in design documentation. It is a small addition but it may interfere with default schema composition state so we wanted to be careful around testing it.

Small items that we can quickly resolve:
- [x] Flux Sync should be turned on by default.