Should list rule apply to role="list"?

### Product

axe-core

### Product Version

4.8.3

### Latest Version

- [X] I have tested the issue with the latest version of the product

### Issue Description

#### Expectation
The issue caught by the `list` rule has the same AT impact (at least in chrome/voiceover) regardless of whether a list is defined using `ol`/`ul`/`li` elements or `role="list"`/`role="listitem"` elements. In chrome/voiceover, if either kind of list contains non-listitem content (eg, `

`), it causes the AT to make confusing announcements where different parts of the list content are announced with inconsistent list item counts.

I think the inability of ATs to understand the structure of the list makes this a 1.3.1 violation regardless of whether it's a semantic or aria list.

#### Actual
The `list` rule doesn't report violations for custom lists defined using `role="list"` + `role="listitem"`, only for semantic `ul` and `ol` elements.

In some variations of this, `aria-required-children` will catch the explicit-role case, but only if the extraneous elements are detected by `getOwnedRoles` - currently, it explicitly skips cases like the second block below because the extra content's element isn't focusable and doesn't have any role or aria attributes.

#### How to Reproduce
```html

Semantic list (list violation)

extraneous content


• item A


• item B


• item C

Explicit-role list (no list or aria-required-children violations)

Explicit-role list (aria-required-children violation)

```

#### Additional context
Originally reported internally by @JaiRai0304

I would guess that part of the original justification for this rule is likely that [the HTML standard](https://html.spec.whatwg.org/multipage/grouping-content.html#the-ul-element) defines the content model of `ul` and `ol` elements as being "Zero or more li and script-supporting elements". This helps justify the semantic case as a 1.3.1 violation, but I think it's still a violation even in the explicit-role case.

The `list` help text and help page are more actionable for this specific failure than `aria-required-children`, but if we do expand `list` rather than `aria-required-children` to account for this case, we'll want to be careful to avoid double-violations in instances like the third code example above.