[DOC Release] Mark @ember/instrumentation as public

[xg-wang]

Based on description in https://github.com/emberjs/rfcs/blob/master/text/0176-javascript-module-api.md#organize-by-mental-model, @ember/instrumentation is deemed as public module.
#11362 may have incorrectly marked it as private.
Closes #17703
cc/ @chadhietala

[chancancode]

I do think the module itself should be importable (if it's not already), but I'm not sure that we should mark the methods as public. I was under the impression that they are in a similar state as the ViewUtils methods, but I could be wrong.

[xg-wang]

@chancancode What would be the difference if we mark the module as public but not the methods?

[chadhietala]

From the RFC:

And finally, some packages that may be used by internals, extensions, or addons but are not used day-to-day by app developers:

• @ember/instrumentation - Instrumentation hooks for measuring performance.
• @ember/debug - Utility functions for debugging, and hooks used by debugger tools like Ember Inspector.

And the RFC enumerated what should be exported as public API:

https://github.com/emberjs/rfcs/blob/master/text/0176-javascript-module-api.md#emberinstrumentation

[chancancode]

I think the context was that we agreed to give some reasonably popular intimate APIs an import path (so that they can be used at all), without necessarily committing to semver API stability. There are other private things on there too, e.g. Map, guidFor, runLoadHooks. We can discuss stabilizing them (or perhaps this particular one really is just a mistake), but I was just disagreeing on the fact that it was in the modules RFC automatically implies they are @public. I thought the original bug was that there weren't reachable (not importable) despite what the RFC said.

[rwjblue]

We chatted about this for a bit at the most recent core team meeting. The rough consensus is that these APIs are not what we would prefer them to be, and instead of making them public now we should consider coming up with better alternatives.

To be clear, this does not mean that the @ember/instrumentation APIs are at risk for "randomly being removed", they very clearly qualify as intimate APIs and therefore would require a deprecation RFC and the standard intimate API deprecation cycle (at least 1 LTS must include the deprecation).

[rwjblue]

@xg-wang thank you for spurring the conversation here! I'm going to go ahead and close this PR now that we've discussed and come to a conclusion.