Standardize naming conventions for plugins, config IDs, classes, etc

Problem/Motivation

As we start to actually add code to this project, I'd like us to have a clear, standardized and rigorous plan for what we name things around here. Calling this parent issue / plan "Major" since it blocks progress on other issues.

In particular:

• Plugin IDs
• Config IDs
• Class names

Some places this is already a starting to be a problem:

#2973035: Configurable list widget has a typo in its id
#2834016: Add 'Compact' datetime range formatter

It's also possible that "we" don't like the way I named things for #2845081: Provide a datetime_range widget to define end time via a duration offset (although @heddn RTBC'ed that, so I went forward). :)

Proposed resolution

Initial draft. Please edit! I'm trying to use the MUST, SHOULD, etc convention from coding standard docs, etc.

Field plugin IDs

{field-type}_{feature-name}

Every field-related plugin in here will operate on a specific field type. Generally either datetime or daterange. That MUST be the first part of the plugin ID.

Since the plugins already know what kind of thing they are (widget, formatter, etc) via namespace and otherwise, we don't want that also in the ID.

The _{feature-name} part tells you what feature is provided by that plugin and guarantees uniqueness. If the feature wants multiple words, separate with more underscores.

For example:

daterange_duration
daterange_compact
datetime_configurable_list

Other plugin IDs

TBD
None yet, but maybe we'll start adding other things (blocks, etc).

Config IDs

MUST start with datetime_extras. (including the period).
Otherwise, attempt to match the _{feature-name} part of the ID from any related plugins. TBD. Waves hands. ;)

Class names

Plugin classes MUST follow the agreed upon plugin ID format, plus existing core conventions.
Examples:

daterange_duration > DateRangeDurationWidget
daterange_compact > DateRangeCompactFormatter
datetime_configurable_list > DateTimeConfigurableListWidget

Services

Service IDs MUST have at least:

datetime_extras.{service-name}

Service IDs SHOULD have the form:

datetime_extras.{feature-name}.{service-name}

Example ID: datetime_extras.daterange_compact.formatter
Example class: Drupal\datetime_extras\DateRangeCompactFormatter

Remaining tasks

1. Finish drafting the proposal, and make sure the plan covers everything we care about covering.
2. Get agreement and sign-off from as many datetime_extras maintainers as possible:
   • @dww (here)
   • @heddn (in Slack)
   • @jhedstrom (in Slack)
   • @mpdonadio (here)
   • @pjonckiere
   • @vijaycs85
3. Document the plan somewhere other than this issue. In CONTRIBUTING.md via #13 and #14.
4. Unblock child issues (done) and rename whatever needs renaming (see child issues).

User interface changes

None.

API changes

None.

Data model changes

None.