fix(material-experimental): use harnesses for mat-option

[crisbeto]

Follow-up from #16620 and #16710. Adds a dedicated harness for mat-option and mat-optgroup.

Note that some of the code is duplicated. This is because we don't have a shared place where to put the harness so that mat-autocomplete and mat-select don't have to depend on each other. I've intentionally kept the harnesses to only the methods we need, but once we have experimental/core, I'll combine them and implement all of the states that are supported by mat-option.

[mmalerba]

See comments below

[crisbeto]

Sorry for the delay @mmalerba, I must've missed the notification. The feedback is addressed now.

[mmalerba]

Now that BaseHarnessFilters has some built-in options, we should give all classes a static with function. This will allow users to filter based on selector or ancestor element

[crisbeto]

@mmalerba I've addressed the latest set of feedback.

[mmalerba]

Did we want to make this optionally take a HarnessPredicate? I seem to remember discussing that at some point. So we can search for a specific option more easily

[crisbeto]

I'm not sure what that would look like. Here's what I got to compile, but it feels a little weird so I don't know if it's correct:

async getOptions(predicate?: HarnessPredicate<MatSelectOptionHarness>): Promise<MatSelectOptionHarness[]> {
  return this._documentRootLocator.locatorForAll(predicate || MatSelectOptionHarness)();
}

[mmalerba]

Sorry, I think I meant OptionHarnessFilters not HarnessPredicate. That way people can do getOptions({text: 'Option 1'}). Under the hood that would use a harness predicate: ...locatorForAll(MatSelectOptions.with(options)). My bad for not explaining that right

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}