Satisfy linter for gh-2622

[jugglinmike]

Hello, @jongund! During today's APG Task Force meeting, I offered to take a look at the linting failures in gh-2622. Here's my proposal for a solution!

It's not exactly what I suggested "off the cuff," because I've gained additional context that influenced my opinion here. Namely: it's that the "global namespace object" pattern is used elsewhere in the project. Although we know there are better methods for code sharing, it seems wise to defer addressing that for another day (when we can address the issue holistically) and to focus today's patch on the stated problem.

Fortunately, your decision to introduce ES6 classes doesn't interfere with the namespace pattern. If we use a "class expression" rather than a "class declaration," we can assign each class to a property value rather than a variable binding. (In this form, the identifier following the class keyword is optional, but we'll leave it there, anyway, for debugging purposes. Doing so will ensure that the names Listbox and Toolbar are still associated with the class values in error stack traces and such.)

If we take this approach, we won't have to modify the ESLint configuration, after all.

(To be clear: it's still true that we can fix those linting errors solely by changing the ESLint configuration. If we choose to do that instead of applying this patch, we'll want to make sure to add the names to the right place in the file named .eslintrc.json: the "overrides" for files with .js extensions. Although it might be even better to add the configuration "in-line" in the example files where we expect the variables to be available globally; that's done with code comments like /* global Listbox */. That way, ESLint would continue to correctly warn us if we accidentally referred to Listbox or Toolbar from some file where those aren't available.)

---

WAI Preview Link (Last built on Thu, 09 Mar 2023 21:30:16 GMT).