Evaluate testing APIs that components should expose to client applications

Copied from User Story 1537054: Evaluate testing APIs that components should expose to client applications

(See also the comments in that US)

It should be easy for a client application to write a test which includes a component in the page, configures it, interacts with it, and inspects its visual state.

We've had good success following Angular Material's test harness/page object pattern and we had many challenges with the testability of Smart elements. We should evaluate what testing APIs the nimble components need to expose to be delightful for client applications to consume them.

The primary goal for now is Angular client applications, but we should see if we can write this layer at the nimble-components level so that other frameworks could take advantage of it too.

Current status

A branch exists that includes:

• a page object for the combobox
  • built using testing-library user events
  • includes unit tests that are passing
• re-export the page object for Angular
  • includes unit tests that are not passing

A not building branch exists that shows what it looks like to use that page object in an Angular app.

Possible next steps

1. fix angular tests
2. write page objects for more components (see comments in this issue for some interesting ones)
3. figure out cases where page objects might need to expose read APIs (e.g. breadcrumb)
4. think about code sharing with playwright tests and how page objects would bubble up to apps.
   • see playwright testing library for ideas about locators
   • think about whether we could single source page objects for both testing frameworks despite them having different models for input events