Add more functionality to _regionshowschema shows

[MorTimerPlay]

_regionshowschema(.yml) shows are currently a limiting factor in the dynamic SS3 environment.

Functionality to parse custom arguments to setup, loop and cleanup shows would be beneficial. This should expand the current ability to pass along the region name to make region shows more flexible.

This would eliminate the need for extra shows e.g.:

_regionshowschema.yml starts ShowA.groovy without the possibility of arguments -> ShowA.groovy sole purpose is to start ShowB.groovy with arguments

The ability to definite variables within _regionshowschema would make ShowA obsolete.

Ideally these variables could also be computed dynamically within the _regionshowschema show. For example for the sake of running different variations of loop shows for different amounts of players within the region.
––––-
To go a step further, the actual shows and delays for loop shows could be dynamic. This may be used to decrease the frequency of performance-heavy loop shows depending on the amount of players in the vicinity. The ability to switch between different shows, could be used when the changes can't be achieved efficiently just by chasing arguments.

In conclusion, all the proposed features can already be achieved in some shape and form, but the functionally within _regionshowschema would streamline the show sequence and provide a one-stop/single file solution for a lot of dynamic processes, which currently need to be spread across multiple shows. The _regionshowschema show would act as a master parent file with clear branches, something 3 independent setup, loop and cleanup files do not provide.

[RyanHecht]

Perhaps we should allow for region show schemas to be defined as a Groovy DSL:

regionshow {
  region "region" // could also accept a list of regions
  setup { // maybe these should also accept the parseNow flag so you can optionally run the code at runtime or at load time
    "path/to/the/setup"
  }
  loop {
    "path/to/the/loop"
  }
  loop(delay:20) { // additional loop shows are new blocks, optionally allow for delays to

  }
  cleanup {
    "path/to/the/cleanup"
  }

}

I'll think about this more but I think this is a good place to move towards