Nested state machine2

[Eyap53]

Generic PR

• Do you have a forum thread linked to this PR?
  Yes : threads/state-machine.979371

• What will this PR bring to the project for everyone?
  It had a new nice functionality (nested StateMachine), that also help with separating the StateMachine, making things more comprehensive when looking at the Table. See below for an example.

• How did you implement them?
  I just added a new ActionSO, that reference the SM-table.

Practical example :

As it may rise UX questions, I decided to implement a little example, which is also in this PR. It concerns the StateMachine table of the slime critter.

The StateMachine for the slime critter was like this :

and is now reduced to this :

It's still complicated, but a people taking a look at this table won't have to understand the relations between the two previous states. Instead, when they understand the fighting relations, they can then go look at the roaming table :

In the process, a few transitions were removed. And a few conditions for some transitions were also removed. Indeed, previously both Idle and the previous Roaming were adding conditions that are not necessary anymore :

Note that this other table can be used as-is for another critter, even if the parent table is different ! So it also add re-usability.

[CLAassistant]

All committers have signed the CLA.

[ciro-unity]

Hmm, having the "example" build on top of existing transition tables means we will probably have a conflict once I'm done with the PRs I'm reviewing... isn't it possible to build it as an independent one?

[Eyap53]

I restored the previous SM table, and created a new one with the mentioned improvements. I switched the SM table reference in the Slime Critter prefab to the new one (the simplified version).
I also reflected the improvements made in the last PRs to the simplified table.

Note that while adding the new condition "IsTargetDead" to the old SM, the transition from the "Roaming" state to the "Idle" state was forgotten (Do not cause a big visual problem, but I don't think it was intentional). Thus proving my previous point that redundancy is error-prone and the validity of my example. I fixed this transition in my last commit.