[Feature Request] Document z-index usage and add some logic to it

Context

• This issue is not a bug report. (please use a different template for reporting a bug)
• This issue is not a duplicate of an existing issue. (please use the search to find existing issues)

Description

z-index across Monaco appears to not follow any logic. I'm putting a full-screen overlay over the editor and just realized you can still drag the handle between the two halfs of the diff editor. Looking at the CSS it has a z-index of 35:

.monaco-sash {
    z-index: 35;
}

I'm sure I will eventually run into more issue, e.g. with modal overlays or my fixed positioned autocomplete results.

Searching through the Monaco CSS shows z-indexes ranging from 1 to 10000 with no apparent logic (e.g. 5, 10, 40, 41, 50, 100, 2500, 10000).

In the app I'm currently working on I have cleanly structured z-index like this:

:root {
  --z-index-grid-header-footer: 1;
  --z-index-main-menu: 2;
  --z-index-spinner-overlay: 3;
  --z-index-resize-handle: 4;
  --z-index-suggestions: 5;
  --z-index-dialog: 6;
  --z-index-help: 7;
  --z-index-toasts: 8;
}

Now I could go ahead and change them from 10001 to 10008 to make sure they are always on top of Monaco (that's exactly the benefit of having them in a central place). But what if tomorrow Monaco adds an element with a z-index of 20000? Or why not 999999?

Any thoughts on how to make embedding Monaco more predictable? I assume the current state has grown historically and is depth from VS Code. This has caused problems in the past https://github.com/microsoft/monaco-editor/issues/2203

Search Monaco's CSS for the z-index declarations and inspect the .monaco-sash rule that uses z-index: 35. Read the discussion, including issue #2203, to understand prior embedding problems; the issue does not name files, tests, or a concrete definition of done, so the scope and acceptance criteria need to be established first.