Add title-related methods to BlockPluginInterface to help clarify and resolve many issues

We have a ton of issues related to block titles, and we've been working ourselves up into an ineffectual tizzy over them for several months now. I'm hoping this issue can fix a lot of that by clarifying the undergirding issues, proposing some basic API & responsibility changes, and make princess happy in the process.

In all the issues I've read, there's no one place that we've clearly outlined the requirements for 'titles' on blocks. So, let me start with that:

• We need a listing label for the UI at admin/structure/block/list/block_plugin_ui:bartik/add (in Bartik) - that is, the list of block plugins + derivatives. At this point, all we have access to is data from the annotation, and we should endeavor to be content with it.
• We need an administrative label for the UI at admin/structure/block. At this point, we have a block plugin + configuration/block entity, but no context (that is, Request/route)-based data. We should also show this title in the UI regardless of the state of the 'Show title' checkbox. It's also being discussed in #1875252: [META] Make the block plugin UI shippable and implemented in #2014191: Implement the block-by-theme listing page, that two columns are presented: the frontend-facing title, and the administrative label. For the UI we have, I like this two-column suggestion.
• We need the frontend-facing title for the block, for use at request time. Here we have everything - the block plugin, the configuration/block entity, and the real Request context in which we're operating. We also need to respect the 'Show title' checkbox in this case.
• We also need to be able to accommodate showing the fully contextualized frontend title of the block for non-request time purposes like previews, regardless of whether the state of the 'Show title' checkbox.
• Currently, the machine name is also conflated with the rest of this system, in that it is initialized to be the admin label declared on the annotation. This is silly, and I have a fix for it in #2022897: Shift responsibility for creating unique config id/machine name off of (views) block plugins and onto BlockFormController that disentangles machine name from title by adding a new BlockPluginInterface method. So let's not talk about machine name AT ALL in here, please :)

That is a maximum of four "titles" for a block: listing, administrative, context-free frontend, frontend.

Right now, we collapse listing and administrative together, using the 'admin_label' from the annotation. This does have the drawback of hiding the frontend title, albeit a context-free version of it, from the user. If we go with the dual-column approach, then we get both the context-free frontend and administrative, and it should be hunky-dory. Now, we sometimes think we see the frontend title in the administrative context because we default the 'label' from the 'admin_label' right now...but that horrible little masquerade just makes the whole thing way more confusing by hiding that there's a difference between the administrative and context-free frontend titles.

The rest of the issues stem from the fact that we - almost proudly - make no distinction between context-free frontend and real frontend title. We do that in large part because, somewhere along the way, we got the idea that creating a block title was a configuration task, and not something the block plugin knows anything about. Views is butting hard into this now, with the latest (and most productive issue, I think) being #1957276: Let users set the block instance title for Views blocks in the Block UI. I think the only problem with that issue is that its focus is too narrow, because...

When it comes to block titling, Views is not the exception. It is the rule.

In all these months of back-and-forth we've had about "what IS the block, the entity or the plugin?", we've lost sight of a crucial reality: Blocks are not user-created content. (Not even custom blocks are - the UNDERLYING entity is user-created content, but not the block plugin derivative spawned from it. Blocks are portable bits of rendering logic that can be configured to behave in slightly different ways. They often pass through to grab user-created content, but they themselves are not the content. They are rendering logic. In fact, the little masquerade of defaulting 'admin_label' into 'label' is evidence of this: even though we're not admitting it, we clearly already believe that the block has a good idea of what its title should be. As such, it is perfectly reasonable to expect block (plugins) to have opinions about what ALL of their output is. Including how they are titled, in all its variations. And for a domain object to "have an opinion" about something, that means it has a method. So...

This patch introduces four new methods to BlockPluginInterface:

• getDefaultTitle() - the block returns a raw, untokenized title that is available without any configuration or contextual data injected (not that core is worrying about that yet). In other words, this is where the block plugin reports what it thinks the user-facing title should be.
• getRawTitle() - the block returns a raw, untokenized title. The plugin should be able to produce this title without any contextual data injected, but can safely assume it is acting on a properly instanced block (that is, configuration have been injected). This will just call back to getDefaultTitle() in most cases; the use case we have for this in core is so that the block can let a title override entered by the user supercede its own default.
• getTitle() - returns the fully-processed title string, exactly as it should be passed along for final output to the user (though still in need of escaping). This requires both an instanced block and contextual data to be present.
• isTitleVisible() - returns a boolean indicating whether or not the title should be visible in a final frontend rendering scenario.

Note that, conceptually, the 'admin_label' annotation property is kinda of part of this API, as it should be considered the sole source for the administrative listing label use cases, as described above.

The code should make it clear that we still allow users to "set titles" on blocks - we're just changing the paradigm from it BEING the title, to it being a title override. If the user does not explicitly choose to make use of that override, then the native title logic from the block itself is used. And, unlike now, it's easy to allow the user to stop overriding the block and return to the native default supplied by the block plugin. merlinofchaos alluded to this in #1957276-38: Let users set the block instance title for Views blocks in the Block UI, though I think he should have been more forceful about it: the 'override title' mechanism is one we've used in Panels for years, and it's one of the things that actually works WELL. Combine it with an interaction flow akin to the one proposed by yoroy (the third one there), and we have a winner.

Once we do this, we can have calling code stop making the shitty assumption that everything extends from BlockBase, or at least utilizes the exact same datastructure rules. That means that template_preprocess_block() can call methods instead of inspecting magical keys in a stupid freakin array. Much more importantly, though, ViewsBlocks no longer need to set their title on $configuration['label'] (because THAT makes sense) during build() - nor will any other more complex blocks that are written in contrib (or princess). This is rather important because the implicit reliance on the 'label' array key effectively makes the BlockPluginInterface a lie.

Note that I'm not proposing we necessarily fix all of the UIs to be all happy-perfect in this issue. We should change the API in this issue, update things where necessary to get tests green, then fix the UIs in followups/the existing open issues once this is in.