Cleanup display and seperate options from instances

I will work on that.

Added tests and refactored one function:

a5f411b get the paths without instanciating the displays
33dd513 add tests for getDisplayList, getPath and addDisplay

The main issue with doing that at the moment is that for example the wizard is using
the active handlers to save values and the handler itself has logic we need in methods like
getItems (for example override).

We should probably store a reference to $storage->display['id'] which is an array of the options
directly in the display handler.

Some ideas:

• ViewExecutable::displayInstances + ViewStorage::display
• ViewExecutable:displayHandlers
• ViewExecutable:display ViewStorage:displayOptions

My favourite is option two at the moment, maybe you have another preference?

At the moment views most often uses singular for multiple instance of objects (like the database tables), for example view->filter, view->field
so i think if we do it, we should do it later but for all of them.

50c918a write tests for ViewStorage::add/set/getItem(s) and fix one issue in ViewStorage
145e6e7 first introduction of displayHandlers and some tests for the methods

Let's first introduce $executable->displayHandlers and then remove the ViewDisplay objects.
At the moment i just wrote test and converted the tested methods to the new array.

9a13d78 let the plugins just store the display handler instance instead of the viewDisplay and adapt all the function calls
697a258 convert a lot of usages of display handlers to the new array

So let's retest it.

One less php fatal

Let's see whether this is better

-        $output .= theme(views_theme_functions('views_view_grouping', $this->view, $this->view->display),
+       $output .= theme(views_theme_functions('views_view_grouping', $this->view, $this->view->display[$this->view->current_display]),

I totally think that could be made better, what about storing a reference to the display options in the display plugins?
From the runned local tests this could be green aka. good to go on an work on ViewDisplay.

Started to remove the viewDisplay object and replace every place which uses it, this change
is currently not committed but i would like the bot to run on that.

Some more fixes, tsss still not 200kb

Even more fixes.

This could be it, yes 200kb!

At least the amount of fails/exceptions and passes were sort of symmetric.

+++ b/lib/Drupal/views/Plugin/views/PluginBase.phpundefined
@@ -27,6 +27,15 @@ abstract class PluginBase extends ComponentPluginBase {
+   * The display object this plugin is for.
+   *

This doesn't sound good!

+++ b/lib/Drupal/views/Plugin/views/PluginBase.phpundefined
@@ -164,7 +174,7 @@ abstract class PluginBase extends ComponentPluginBase {
+    return views_theme_functions($this->definition['theme'], $this->view, $this->view->display[$this->view->current_display]);

@@ -174,7 +184,7 @@ abstract class PluginBase extends ComponentPluginBase {
+        $funcs[] = views_theme_functions($theme, $this->view, $this->view->display[$this->view->current_display]);

This could be $this->view->display_handler instead.

For the rest i'm to tired now

Not bad: 75 files changed, 836 insertions(+), 772 deletions(-)
This patch is one reason to use git commit -a :)