[meta] Lots of non-plugin PHP classes in plugin directories

Problem/Motivation

Plugin discovery requires file directory scanning, loading classes into memory, then reflection to check for attributes.

We have to load the class into memory before we can check for plugin attributes, and this memory then can't be freed again.

Core has more than 100 classes that are in plugin directories, but are not plugins, or are different plugins.

For example

Convert.php
CreateNew.php
Crop.php
Desaturate.php
GDImageToolkitOperationBase.php
Resize.php
Rotate.php
ScaleAndCrop.php
Scale.php

These are ImageToolkitOperation operation plugins, which are in core/modules/system/src/Plugin/ImageToolkit/Operation/gd

But because they're in core/modules/system/src/Plugin/ImageToolkit they get parsed in case they're ImageToolKit plugins, this loads all the classes into memory and requires FileCache to store 'null' entries (which include mtime etc. in reality) in APCu.

If we move the GD toolkit operations into a parallel instead of nested directory, then we wouldn't be parsing them twice (or at all, when we only get the toolkits and not the operations).

There are various other cases, some base classes which will be annoying but probably worthwhile to move, some helper classes in Views it looks like.

Plugin discovery has explicit logic for when it discovers non-plugins so we can add an Exception there to start building a list.

Steps to reproduce

Proposed resolution

Move base classes/interfaces to src/Plugin
Move plugins to their own 'type' directory, src/Plugin/my_plugin_type/plugin_name.php

Remaining tasks

Move classes around
Update Plugin API documentataion

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet