Issue title: Add hooks for Layout presave/insert/update
 Issue body: If I add a configurable block and click "Add block" hook_block_save is called immediately. If my module saves data, it is saved at this point. But what if the user changes his mind and clicks "cancel" instead of "Save Layout"? The block isnt added but I have data saved as if it is.
Is there a hook_layout_saved() equivalent that I could use to clear this data in that case? 

 Comments: 
 Comment 0: If it's a per-instance configuration, you may not need to use hook_block_save() at all, because the configuration for that block will be saved into the Layout config file. You could also use hook_block_save() to modify the $edit values by reference, affecting _which_ values are saved into the layout.

 Comment 1: Understood, but I meant if I wanted my module to DO stuff when a block is saved. Say I want each block instance associated with three entities which should have the block ID saved as a property on those entities themselves. I would have to execute the function that saves this property in hook_block_save, right? Its not a block setting. In D7 once you've saved the block config form, that's it, the block is saved, you're good. Here though, its not done yet, cause you have to click save layout to actually save the block, and there's no way to tell your module, "oops, remove that property on those entities, Bob changed his mind".
Hope you understand.
 Comment 2: Wow, yeah that's quite the use-case there!

It sounds like what we need for this situation is `hook_layout_save()`, or should we have a separate presave/insert/update hooks for this occasion? Let's check for consistency, evaluate, then add the approach that makes the most sense.

We can't change `hook_block_save()` at this point for 1.x. But if this turns out to be really irritating, we can evaluate renaming it for BD2. 
 Comment 3: > Wow, yeah that's quite the use-case there!

made that up on the fly too!
`hook_layout_presave/insert/update()` would be hsmith@example.net. I dont know enough about what goes on in Layout to say more than that for now. 
i think though the current `hook_block_save()` would be better called `hook_block_presave()` but thats 2.x I'd agree.
This needs a milestone tag then.

 Comment 4: > ...we can evaluate renaming it for B2.

I know this is your baby Nate and you have every right to come up with short names for it, but please lets avoid using plain "B" for Backdrop and make a habit of using "BD" instead. You see, if we start calling them B1 and B2, some (especially here Down-Under) might make [the wrong connection](https://www.google.com.au/search?q=bananas+in+pyjamas).

 Comment 5: ...sorry I couldn't help it :stuck_out_tongue: 
 Comment 6: > You see, if we start calling them B1 and B2, some (especially here Down-Under) might make the wrong connection.

LOL, there could be worse connections.

I actually typed "BD2" first, but then I realized that would reinforce the improper capitalization of "BackDrop". It's not 2 words, just one, "Backdrop". So that's why B1, B2, B3 seems more appropriate.

> hook_layout_presave/insert/update() would be hsmith@example.net. I dont know enough about what goes on in Layout to say more than that for now. 

Let's use this issue for tracking this change. If we want to pursue renaming `hook_block_save()` let's open an issue for that later. I've renamed the issue to `Add hooks for Layout presave/insert/update`.

 Comment 7: @docwilmot's latest PR at https://github.com/backdrop/backdrop/pull/1017 looks pretty good.

> Added two more candidate hooks. Total now:
> 
> hook_layout_block_removed
> hook_layout_template_changed
> hook_layout_presave
> hook_layout_update
> hook_layout_insert
> hook_layout_delete
> hook_layout_revert
> hook_layout_disable
> hook_layout_enable

We'll need docs in the layout.api.php file for all of these. And in truth, all of these should be tested with a test module that checks all the hooks are called with the right parameters and that the event is fired when expected (see `entity_crud_hook_test.module` for an example).
 Comment 8: Excellent. This was the first pass for review. API docs and tests to follow. 

 Comment 9: @quicksketch  help with `$_SESSION` please
I adapted `entity_crud_hook_test.module` as suggested, putting the following in a test module:

```
/**
 * Implements hook_layout_insert().
 */
function layout_hook_test_layout_insert($layout) {
  $_SESSION['layout_hook_test'][] = (__FUNCTION__ . ' called');
}
```

And checking the variable in the test file:

```
      $position = array_search($message, $_SESSION['layout_hook_test']);
```

The hooks are called perfectly, but the `$_SESSION` variable isn't shared between the module and the test file. `debug($_SESSION)` gives two different `$_SESSION` arrays if called from module vs test.

I'm wondering if this is because this implementation differs from `entity_crud_hook_test.module` in that I'm creating and saving layouts across multiple page requests with redirects while `entity_crud_hook_test.module` does everything in one request.

In summary can this be done using `$_SESSION` or go with `config()` to set data?

 Comment 10: > In summary can this be done using $_SESSION or go with config() to set data?

Yeah, the session is indeed separate between the test methods and the testing browser that makes all the requests. If you wanted to check the contents of the session in the test browser, I think you may have to make a page callback in your test module that prints out the content of $_SESSION in which you're interested.

If you want to use a persistent storage instead, you could use `state_set()` and `state_get()`. You could use `config()` as well, but `config()` is intended for storing cross-environment configuration. If this is just for testing, using state may be easier and a bit more efficient, as you don't need to use hook_config_info() or include a default config file.
 Comment 11: I can have this done in the next hour. Would it be possible to get in to 1.2.0 or are we at a freeze now? I'd really like to get it there.
 Comment 12: This is looking really good. If you can get the documentation hammered out and the tests finished (if there's more to do) then we should be able to include it.
 Comment 13: A bunch of feedback posted to https://github.com/backdrop/backdrop/pull/1017. This is looking really good! Wow, killer job on those tests! Writing tests is not easy, especially for navigating the Layouts UI with all its links and AJAX behaviors (which you don't have in the testing suite of course).

The biggest issue I encountered was the difference between `hook_layout_block_delete()` and `hook_layout_block_insert()`. It seems very strange that they are executed at two different times. Delete happens when the block is removed (but not yet saved). While insert happens at save time. Is that right? This may be a reflection of the internal Layout API, but I don't think that it fits well in a public API for other modules.

I'm going to mark this for 1.2.0 so it's in the list and I don't forget about it.
 Comment 14: From the PR, @docwilmot noted the actual difference in `hook_layout_block_add()`:

> Just to be clear, note the 'programmatically' in the description. This hook does not fire at all when the UI is used because Layout38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5lock() isn't called anywhere. We'd need to fix that first and I think this is beyond the scope of this PR.

So this hook isn't actually fired at all (except by tests).

Overall, I'm actually having a bit of trouble figuring out what purpose these hooks would serve developers. They're not actually at the point of saving (you'd need to use `hook_layout_presave()` or one of the other layout hooks). I'd have a feeling that these hooks would cause confusion by developers thinking that the "add" or "remove" events would naturally be at save time, rather than in the middle of an unsaved configuration.

 Comment 15: So @docwilmot, I think if this were to slide into 1.2.0, the way to get it there quickest would be to kill `hook_layout_block_add()` and `hook_layout_block_remove()`, and get those sorted out in a way that makes sense in 1.3.0.

 Comment 16: Actually these are the two only important goods to me really, having done a few block hooks so far. Perhaps the terminology is the issue here, but these are hooks which would fire when a block is added to a layout but before the layout is saved. This is really necessary because hook block save doesn't differentiate between adding to the layout UI and saving. So when you click add block in the dialog, hook block save fires even if you have a million more things to do in the layout UI, it's done. These two hooks can let module know what you're doing while adding, removing blocks in the UI. 
All the other hooks are for completeness really. These two are the essential ones. 
I've added a hook invocation in the admin form submit function to match the invocation in the addBlock function for when a block is added via the UI. 
Sorry, but I'm typing on a phone because I don't want this to be misunderstood. 
Hoping I'm not misunderstanding you
 Comment 17: edits above
 Comment 18: Actually, youre right, as usual. You could just check on hook_layout_save() to see if your block settings exist, and act from there. I'm over(under)thinking this. 

Nixing now. Thanks for the oversight, as usual.

 Comment 19: > You could just check on hook_layout_save() to see if your block settings exist, and act from there. 

Yeah, as a backup until we could get these hooks making sense, that's what I had been thinking.
 Comment 20: Elaborating on what we *could* do in the future for hook_layout_block_add() and hook_layout_block_remove(): instead of firing these at the time the block is added/removed on the in-progress configuration, we could specifically detect which blocks were added/removed in `Layout38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5save()`. This way the hooks would only be fired when the config was actually being saved, rather than on in-progress configuration.

But overall doing it that way would only provide a short-cut. This could already be done with `hook_layout_presave()` in the current set of hooks, as you said above.
 Comment 21: Great, now with these `layout_block_*` hooks removed I don't have any reservations. Merged in https://github.com/backdrop/backdrop/pull/1017. Thanks @docwilmot!
{'source': 'GithubIssues', 'repo_name_with_owner': 'backdrop/backdrop-issues', 'issue_id': 58504737, 'repo_stars': 137.0}