[meta] Add @Event to all events defined by drupal core

In the issue summary for the other issue, I proposed that the documentation should include:
- What the event is
- What it is used for
- What kind of $event object is passed along.
- @see links to related classes (event class, representative class where event is dispatched, representative class where event is subscribed to).

Let's treat this as the "gold standard" for great event docs; at a minimum I think we want to make sure we have the first three items documented.

As a note, the example in the issue summary is maybe not great. It seems like the first-line summary should probably be standardized... maybe something like:

Indicates a termination event, which is triggered when ...

???

Hm. The suggested doc block needs a one-line summary... and normally one-line summaries are not declarative sentences like "The foobar function does this" or "The FOOBAR constant is this", but more like "Calculates the foo of the bar" for functions, and "Indicates that foo is very bar-like" for constants.

So again, I'd suggest we adopt a standardized one-line summary, something more like:

Denotes an event at the very beginning of request dispatching.

or something like that. (Indicates? Encodes? Denotes? I am not sure what verb to use.)
Also any mention of a class in a doc block should start with a fully-qualified namespace, so \Symfony\... (start with backslash).

And we do not use @api in our docs.

added beta evaluation to summary.

moved summary reason outside the table so it showed after the table.

I like the example currently in the issue summary.

Here's a list of the events I could find dispatched by some Drupal component or another. Based on searching for uses of EventDispatcher::dispatch(). There may be others but this is what I could find.

Should we open separate tickets for each set of events so that it's easier to review, or just do them all in this ticket?

ConfigEvents
$this->eventDispatcher->dispatch(ConfigEvents::DELETE, new ConfigCrudEvent($this));
$this->eventDispatcher->dispatch(ConfigEvents::SAVE, new ConfigCrudEvent($this));
$this->eventDispatcher->dispatch(ConfigEvents::RENAME, new ConfigRenameEvent($config, $old_name));
$this->eventDispatcher->dispatch(ConfigEvents::IMPORT, new ConfigImporterEvent($this));
$this->eventDispatcher->dispatch(ConfigEvents::IMPORT_VALIDATE, new ConfigImporterEvent($this));
$this->eventDispatcher->dispatch(ConfigEvents::COLLECTION_INFO, $this->configCollectionInfo);

EntityTypeEvents
$this->eventDispatcher->dispatch(EntityTypeEvents::CREATE, new EntityTypeEvent($entity_type));
$this->eventDispatcher->dispatch(EntityTypeEvents::DELETE, new EntityTypeEvent($entity_type));
$this->eventDispatcher->dispatch(EntityTypeEvents::UPDATE, new EntityTypeEvent($entity_type, $original));

FieldStorageDefinitionEvents
$this->eventDispatcher->dispatch(FieldStorageDefinitionEvents::CREATE, new FieldStorageDefinitionEvent($storage_definition));
$this->eventDispatcher->dispatch(FieldStorageDefinitionEvents::DELETE, new FieldStorageDefinitionEvent($storage_definition));
$this->eventDispatcher->dispatch(FieldStorageDefinitionEvents::UPDATE, new FieldStorageDefinitionEvent($storage_definition, $original));

RenderEvents
$this->eventDispatcher->dispatch(RenderEvents::SELECT_PAGE_DISPLAY_VARIANT, $event);

RoutingEvents
$this->dispatcher->dispatch(RoutingEvents::DYNAMIC, new RouteBuildEvent($collection));
$this->dispatcher->dispatch(RoutingEvents::ALTER, new RouteBuildEvent($collection));
$this->dispatcher->dispatch(RoutingEvents::FINISHED, new Event());

BlockEvents
$this->dispatcher->dispatch(BlockEvents::ACTIVE_CONTEXT, new BlockContextEvent())->getContexts();

This block event, which is just a string and not a constant. Bug?
core/modules/block/src/BlockForm.php
BlockForm::form
$form_state->setTemporaryValue('gathered_contexts', $this->dispatcher->dispatch(BlockEvents::ADMINISTRATIVE_CONTEXT, new BlockContextEvent())->getContexts());

LanguageConfigOverrideEvents
$this->eventDispatcher->dispatch(LanguageConfigOverrideEvents::DELETE_OVERRIDE, new LanguageConfigOverrideCrudEvent($this));
$this->eventDispatcher->dispatch(LanguageConfigOverrideEvents::SAVE_OVERRIDE, new LanguageConfigOverrideCrudEvent($this));

I think we should make separate issues for the different modules/components.

I don't see the problem with the block event. It looks like the first argument to dispatch() is still a constant?

And by the way, the API module is ready to display @Event on api.drupal.org on the new Events topic... once we deploy a new version to api.drupal.org anyway, which I'll probably make happen in the next two weeks. Hooray! It already works on my test site with the Symfony events, which already have @Event in them.

Update: as the Symfony events already have @Event on them, and the API module is deployed, they are now being displayed on api.drupal.org here:
https://api.drupal.org/api/drupal/core!modules!system!core.api.php/group...

The sooner we can get this done with our event constants, the better!

I created new issues for each of the event "groups", and made this issue the parent for each of them.

- #2415505: Add @Event documentation to all ConfigEvents
- #2415507: Add @Event documentation to all FieldStorageDefinitionEvents
- #2415511: Add @Event documentation to all RenderEvents
- #2415513: Add @Event documentation to all RoutingEvents
- #2415515: Add @Event documentation to all BlockEvents
- #2415519: Add @Event documentation to all LanguageConfigOverrideEvents

Perfect, thanks!

I think we can close this now. All of the child issues are resolved.

I also updated https://www.drupal.org/coding-standards/docs with information about the @Event tag since that didn't get done in #2264049: Create an Events topic, though that got closed already.

Great! Thanks for all the patches too!

https://api.drupal.org/api/drupal/core!modules!system!core.api.php/group...
!!!

So. AWESOME. Thanks so much, folks!!

Semi-follow-up: #2443763: Expose events as plugins.