[treescript] switch from using `actions` to using `behaviors`

Inizia da treescript/src/treescript/script.py alle righe 57-67 e confrontalo con iscript/src/iscript/script.py alle righe 29-50. Fai un inventario delle combinazioni di azioni esistenti e dei workflow merge-day e l10n prima di scegliere i limiti dei comportamenti. Il lavoro è completo quando treescript usa comportamenti con workflow supportati e testabili separatamente, incluse le interazioni descritte tra version-bump, tagging, merge-day e l10n.

In treescript, we currently use actions to determine what logic to run. This follows the mozharness model, and made sense when we first implemented treescript, to allow us to tag, version bump, and/or push independently or together. However, the script has grown in complexity, now supporting l10n bumping and merge day automation, and there are the following downsides to using actions:

1. Various actions are incompatible with each other. Neither l10n bumping nor merge day were designed to work with the current tagging or version bumping logic, so there are caveats when choosing combinations of actions to run.
2. If we make a large change or refactor to one or more of the actions, we need to test to make sure all valid combinations of actions still work. It isn't completely clear which combinations of actions are supported, and which are not.
3. If we want to include or exclude an action in a given set of tasks, we also have to make an in-tree change, and coordinate landing. This likely means we need to run at least one full staging release to test this and (2).
4. It's trickier making a change where an action behaves differently in a subset of cases. This likely means adding a task payload setting, and then making sure that setting is correctly set in all permutations of the gecko taskgraph.

In iscript, we use behaviors to determine what logic to run. Instead of multiple mix-and-match actions per task, there is a single behavior per task. If we need to be able to run tagging separately from version bumping, as well as together, that might mean three behaviors (tag, version_bump, version_bump_and_tag) or a single behavior with flags (version_bump_and_tag, with an empty new_version, for instance).

This doesn't seem like a big win when looking at just tagging, version bumping, and pushing. When we get to merge day automation, however, it's a huge win:

• the merge day behavor can have all appropriate logic baked in. We can test these as appropriate.
  • we may even want to separate these into separate behaviors: merge_central_to_beta, merge_beta_to_release, merge_release_to_esr, bump_esr, bump_early_to_late_beta, bump_central. (bump_central could potentially be part of the merge_central_to_beta task if we wanted, though.) These would duplicate a lot of the same logic, but those could be factored out into simple standalone functions that they each call.
  • we will be able to test these separately, and be able to make more surgical changes if any of these behaviors need different workflows than the others.
• we want to l10n bump after the central_to_beta behavior. This currently necessitates another task, and we have to deal with both a) removing DONTBUILD and b) adding CLOSED TREE, which is a change from the current non-merge-day behavior. We can add an l10n bump helper function call into the merge_central_to_beta behavior function, with the appropriate DONTBUILD / CLOSED TREE settings, and that problem is solved.
• we want to version bump in the merge behavior. We can call the version bump helper function.
• by having a single task handle all of these, rather than multiple disparate tasks, we avoid multiple pushes, and save in both CI compute time and taskgraph complexity.

Not a blocker, but I think moving from actions to behaviors will save us time and headache in the long run.