Detect use of "should" in tests and suggest statements rather than assertions

There are two ways to name tests:

- "should do such-and-such"
- "does such-and-such"

Both styles are valid, but each communicates a slightly different message:

- The first makes an assertion or expectation about the unit of code in question. It is prescriptive and tentatively describes an aspect of the system that is desired but may not be present. It speaks inwardly: it reflects a technical conversation between the programmer and the computer.
- The second makes a statement about the unit of code. It is declarative and confidently describes an aspect of the system that is true today (whether or not that is true). It speaks outwardly: it reflects a more human conversation between the programmer and other programmers.

The extension and mobile teams have tended to use the first style; the Shared Libraries team, the Snaps team, and others tend to use the second style.

I propose that we implement an ESLint rule that checks for the first style and converts it to the second (or at least suggests that it be converted). We can apply this rule selectively to repos that already use the second style to ensure that they keep using it, and we can progressively add it to those that use the first style.

Start by inspecting the repository's existing ESLint rules and configuration structure. Determine how a rule could detect test names using "should" and suggest declarative wording, then define how it would be enabled selectively for repositories or teams using that style.

Written by the indexing model from the issue text.