Split the notion of an Orchestration

[Naros]

Description

In the current design, the code treats the concept of an Orchestration as an OScript. In other words, when a .os file is loaded, the code creates an instance of the OScript resource, which by design is an attachable resource on a node in the scene. But in an effort to extend Orchestrator to support concepts like macro libraries, we need to split this definition.

Implementation ideas

Conceptually, we should aim for something like this:

Orchestration

class Orchestration {
  // All common code here
};

OScript

class OScript : public godot::ScriptExtension, public Orchestration {
  // Implementation of Godot's ScriptExtension
  // Any OScript-specific behavior only
};

OScriptMacroLibrary

class OScriptMacroLibrary : public godot::Resource, public Orchestration {
  // Implementation of the Macro Library behavior 
};

Most code would then take an Orchestration reference rather than an OScript or OScriptMacroLibrary reference. This will allow the plug-in to work with the common contract independent of the actual underlying resource loaded and only branch on the case-by-case scenarios.

This has the added value that as we want to extend Orchestrator to support things such as state-graphs, we've already built the architecture to have a single resource file that can contain a combination of state graphs and other orchestration bits or a defined subset of these based on rule-sets.