chore: split stable and experimental packages into groups using directories

[dyladan]

No description provided.

[codecov]

Codecov Report

Merging #2462 (3ea93ea) into main (5fefbb2) will decrease coverage by 0.72%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #2462      +/-   ##
==========================================
- Coverage   93.32%   92.60%   -0.73%     
==========================================
  Files         135      137       +2     
  Lines        4932     5017      +85     
  Branches     1042     1060      +18     
==========================================
+ Hits         4603     4646      +43     
- Misses        329      371      +42     

Impacted Files	Coverage Δ
...strumentation/src/platform/node/instrumentation.ts	21.79% <0.00%> (-38.47%)	⬇️
...ry-context-zone-peer-dep/src/ZoneContextManager.ts	85.18% <0.00%> (ø)
...es/opentelemetry-context-zone-peer-dep/src/util.ts	100.00% <0.00%> (ø)

[obecny]

In general changes are fine, but I wish to understand how will this be different (or not at all) from what we have now

1. Dev setup, debugging,
2. Working on stable, experimental or mixed,
3. Releasing - how to, what first what 2nd, what will be the command in case of manual etc.
4. Bootstraping examples to be able to "debug on fly"

thx

[dyladan]

1. Dev setup, debugging

No difference except when working on experimental packages you will have to cd into the experimental directory before running commands.

2. Working on stable, experimental, or mixed

No change except when working on experimental you will need to cd into the experimental directory to run commands. PRs that touch both experimental and stable will not work if the experimental changes depend on unreleased stable functionality. You will have to merge stable, wait for release, then work on experimental.

If you want to locally make sure your stable changes work the way you expect with experimental changes before they are released, you can add experimental/packages/* to the lerna.json in the stable root and bootstrap again to tie everything together.

3. releasing

Commands are the same but they have to be run once for each package group. I will port the existing automation from contrib, one for each package group. Will update the releasing md to make this clear. Order does not matter because any PR in experimental which depended on a stable change would not even be able to merge until after the stable is released so it can never be in a broken state. Stable will never depend on experimental.

4. bootstrapping examples

Works the exact same way as it does now. Examples which show off experimental features should be moved to experimental/examples probably.

[obecny]

lgtm

[vmarchaud]

Lgtm