Add loop-unsafe metadata and path flags

[MattWindsor91]

Certain fuzzer actions introduce code that is unstable if looped more than once. These actions need extra flag accounting to make sure that:

1. they don't get generated in loops that aren't guaranteed statically one-iteration;
2. loops that aren't statically one-iteration or deadcode don't surround it (this isn't an issue right now, but will be if we add such loops).

I reckon that a decent way forwards here looks like this:

• add block metadata that tracks whether the block is statically known to execute once (so, we now have 'dead' metadata, 'once' metadata, and absence of metadata implies an arbitrary number of executions);
• as well as the current Is_in_loop flag (which is structural, ie for preventing generation of break and continue outside of the loop), add a new flag: Can_execute_repeatedly (or a better name) that gets inserted whenever we find a loop that doesn't have a deadcode or static-once flag. (We'd need to do it this way so that any loops coming from the initial code always get treated as executing repeatedly.)
• solve point 1 by making fuzzer actions that generate loop-unsafe code treat Can_execute_repeatedly as a negative path filter flag;
• (for bonus points) make the Storelike cycle breaker only kick in if it finds itself in a Can_execute_repeatedly path (in honestly, this would do a better job of fixing the current issues with the cycle breaker and compare-exchange than my safe/unsafe compromise yesterday, but I might just keep that);
• add a new metadata flag, Loop_unsafe (or a better name), that gets inserted on any such action statement. This is similar to the current (moribund) transaction safety code, but would have to be a metadata thing and not a statement class thing because it's a property of how we generate the statement and not what kind of statement it is. This would fix point 2.

[MattWindsor91]

Done now, but I missed the commit reference.