Document cases where it's appropriate to use global \Drupal calls as opposed to DI

Problem/Motivation

General community consensus is that global \Drupal calls should never be used in OO code except in edge cases and scenarios where DI is not possible. However, this philosophy, its reasoning, and how it should be applied are not actually reflected clearly in our standards.

Benefits

If we adopted this change, the Drupal Project would benefit by ...

Three supporters required

1. https://www.drupal.org/u/{userid} (yyyy-mm-dd they added support)
2. https://www.drupal.org/u/{userid} (yyyy-mm-dd they added support)
3. https://www.drupal.org/u/{userid} (yyyy-mm-dd they added support)

Proposed changes

Compile a comprehensive list of situations where DI is not possible/appropriate and \Drupal calls are the only viable option, and add them to a handbook page along with information on why it's advisable to use DI when possible. Some potential cases brought up in the slack discussion on the topic:

@jhodgdon

Drupal is also used a lot in Functional tests.

@larowlan

Entities, field type plugins and data type plugins currently have no scope for DI

@mikelutz

\Drupal calls are also used in core to maintain backwards compatibility. We can’t just add a new dependency injection, we have to make it optional, get it by \Drupal and throw a deprecation error if it isn’t passed so that existing code continues to work, We can eventually make the parameter required in the next major version and remove the \Drupal call

@mxr576

adding a new parameter to a service as nullable, retrieving the service from \Drupal::service() if the parameter is null and triggering and error

I'll add that static methods were brought up a couple of times. But, unless the static class exists in one of the above contexts this feels like code smell and should probably be re-implemented in a service.

For entities, it would seem that https://www.drupal.org/project/drupal/issues/2142515 is relevant.

1. {link to the documentation heading that is to change}

Current text

Add current text in blockquotes

Proposed text

Add proposed text in blockquotes

2. Repeat the above for each page or sub-page that needs to be changed.

Remaining tasks

1. Create this issue in the Coding Standards queue, using the defined template
2. Add supporters
3. Create a Change Record
4. Review by the Coding Standards Committee
5. Coding Standards Committee takes action as required
6. Discussed by the Core Committer Committee, if it impacts Drupal Core
7. Final review by Coding Standards Committee
8. Documentation updates
   1. Edit all pages
   2. Publish change record
   3. Remove 'Needs documentation edits' tag
9. If applicable, create follow-up issues for PHPCS rules/sniffs changes

For a full explanation of these steps see the Coding Standards project page