Add "Add" item to toolbar.

The MR is better categorized "needs architectural review" - it should get some eyes on it to help shape it into a good addition to core. This is the UX meeting approved approach from #84, but there are still choices to be made within that approach. I'm sure there are ways to make it more appealing, but it's doing what it is supposed to do and at a good spot to pick up the baton.

I'm really conflicted about this :)

I feel like I've shut this down on the last iteration and I feel bad about that. I actually like the idea of having this kind of overview, but at the same time, I also feel quite strongly that we have to get this right and and it needs to be the right kind of extensible and live in a sensible place.

Having node branch out to other entity types and the tricks with the node list preprocess and $type suddenly no longer being a node type entity is strange, but I guess the current MR is in a proof of concept phase. Like the links all pointing to node/add/$bundle ;)

For fun, I tried to add it on our project which has a lot of extra contrib modules, just to see what happens. Interestingly, it dies already on shortcut if you have assertions enabled:

AssertionError: Cannot load the "shortcut_set" entity with NULL ID. in assert() (line 261 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).

You can't call createAccess() with bundle NULL on an entity type with bundle, that doesn't actually equal a check to see if you can create an entity of any bundle. I think that extra check can be dropped, instead we need to check at the end if we ended up with any accessible bundle for a given type, a bit like \Drupal\Core\Entity\EntityCreateAnyAccessCheck.

When I do disable that bit, then I end up with the ability to create things like a Shortcuts, Crop, Paragraphs and Webform submissions. I think that shows nicely that this really needs to be an opt-in process. When adding entity reference fields, we have the concept of "common_reference_target = TRUE" on the entity type annotation. We could add a content_add_overview = TRUE annotation to entity types and add it to terms, media and custom blocks as a start.

In regards to bundles, instead of limiting it to entity types with bundles and bundles as config entities, this should use \Drupal\Core\Entity\EntityTypeBundleInfo::getBundleInfo() and while not common in core/contrib, we should maybe find a way to support entity types without bundles too. We don't have too much many of those in core, menu links is one example, but that's tricky to add here anyway. We don't have a standardized way for bundle descriptions nor add links I suppose.

As an alternative to that declarative approach, we could just consider a hook and let other modules add their own sections here "by hand", might not even need to be content entities, could be anything sites consider to be things their editors typically add.

I really like the concept screenshot in #94, I'm not sure how I feel though about the "Other entity types" but I think that's on a really good track. One of the challenges of this issue is fitting everything into the toolbar, but if the "Add" toolbar link simply takes you to this page then I think that's a really good path forward!

Tried testing but didn't get too far

Clicking the "Add content" link throws a fatal error

AssertionError: Cannot load the "shortcut_set" entity with NULL ID. in assert() (line 261 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).

cleared cache multiple times but no luck.

But to echo #96 like the idea of going to a single page. Think it's a very clean approach and addresses the goal.

Thought about cleaning some of the tags but didn't know what was needed for this initiative.

What I think I'm reading here:

- A single url/page as the location for presenting "things you might want to create" would provide a good "UI-infra" basis to build from.
- On which items to get there and how to get them there: [2377543-96], I like the thinking in the last paragraph:

we could just consider a hook and let other modules add their own sections here "by hand", might not even need to be content entities, could be anything sites consider to be things their editors typically add.

. This sounds like a nice approach that leaves things open for contrib to experiment with, which would be a plus I think. Leaving it to the architectural experts to come up with the right technical implementation for this :)
- The mockup in [2377543-94] would already be a good ux improvement as is. I'm thinking about additional features to star/promote items so that they show up as a select list under the "add" in the toolbar etc. But we would still want to introduce this basic page first. Lets focus on that.

Removing tag for now