Move `WAITER_NAMES` to global context to reduce warning log spew when this addon becomes v2 and duplicates are allowed

[NullVoxPopuli]

NOTE: this PR will need to target to the main branch as well (which I plan on doing after all the test apps are implemented)

Context on "The Plan": https://github.com/emberjs/ember-test-waiters/issues/458

historically, we've only been able to allow one copy of test-waiters in a whole projcet. this was forced via build-time code in the v1-addon's index.js. This added maintenance complexity and prevented the conversion to a v2 addon.

With this runtime injection of global state, we can have both the pre-v2 addon and the v2 addon share the same waiter state. Also, in @ember/test-waiters@v3, we can force the existing build-time code to take precedecence with the latestVersion of test-waiters v3 (existing behavior), so there is no risk of old copies of test-waiters not using this runtime highlander code, because those older copies would not be present in the final build of an app.

---

So what does this PR actually do?

• Moves all module state to globalThis
  • getGlobal already existed, so much of this work was already done
  • the WAITERS have already been handled
  • this PR focuses on moving WAITER_NAMES to also be on the global context, so we don't create a ton of log spew.
• More specific types to its clearer what the shape of data is for each of these structures e.g.:

  globalThis: {
  // existing
  [Symbol<'TEST_WAITERS'>]?: Map<WaiterName, Waiter> | undefined;
  // new!
  [Symbol<'TEST_WAITER_NAMES'>]?: Set<string> | undefined;
  }

---

NOTES

• declared compatibility of the 3.x series of this addon include Ember 3.8, which includes IE11 -- so we can't go full native Symbol support yet.

[NullVoxPopuli]

Gonna close this PR because the effort is not worth the benefit.

The changes we want are going to be in the next major anyway, so if folks want the upcoming benefits, they can upgrade and to an overrides/resolution to get the benefit.

The main thing here:

• the list of waiter names is checked eagerly, yet waiters are registered lazily
• the warning is eagerly logged
• we want the map of waiters to be the source of truth

[chancancode]

Yeah we discussed on Discord –

• The critical aspect here, which was the bulk of the work in the original PR, is to ensure the actual waiters map is shared. turns out this is already the case, and we can maintain compatibility with the existing version without requiring forcing resolution, etc, which is nice.
• With that out of the way, the secondary thing that this is trying to move off of module state, is the WAITERS_NAME set:
  • The purpose of this set is to issue a warning whenever a conflict arise – typically this is either a coding error by an addon author or a module is unexpectedly duplicated. Either way it is a error situation and things will be quite broken. It's not entirely clear to me why it is a warning rather than an error, and it's not very clear to me how much things are expected to degrade "gracefully" in these situations.
  • The reason the conflicting name is a problem is that we store the waiters in a map, using the name as the key, inherently that means there can only be one thing with the same name. Since this is ultimately the reason we care, the natural thing to do would be to warn (or throw, even) when trying to register a second instance with the same name, which would also remove the need for a parallel data structure that tracks the same thing (and we don't currently do a great job keeping the two in-sync – we don't remove the names from the set when unregistering, for example, which probably means the unregister API is unusably broken if you intend to re-use the same name).
  • In the current code, moving the warning to the registration side would defer the warning, since register isn't called eagerly in buildWaiter. It would be slightly sub-optimal and make things slightly more difficult to debug when the problem does happen (the problem = a package consuming ember-test-waiters is accidentally duplicated). Personally, I think that is probably acceptable.
  • But it is also not clear that we have a particular good reason to defer adding the waiter to the map in the first place, we can probably just try to move the register call out to buildWaiter (or in the constructor of the waiter) and see if anything breaks, and solve both problems at once.
  • Overall, I think all of these are fine to change, especially since I consider this warning only advisory in nature. However, there are som slight concerns over doing these kind of changes in a minor release, and since we are going to cut a new major imminently anyway, we may as well do it then.
  • If there is a mix of the new legacy version of ember-test-waiters and the new version in the system, we may not always successfully issue this warning. It is probably acceptable since the warning is advisory, but if we want to, we can also try to address this compatibly in the new major by putting a wrapped Map on the global that warn/throw when on the .set method when a conflict is detected.