Add support for running curriculum

[bruno-f-cruz]

General strategy

The launcher will depend on aind-behavior-curriculum and must be able to deserialize a recommendation and ask for a new curriculum suggestion at the end of the session.

Since each curriculum will likely require a different set of dependencies and move at a much different rate than the task acquisition code, we must decouple the two environments.

Finally, we must establish a contract between the launcher and the external application

Implementation

1. Each Curriculum will have its own repository;
2. Each repository will have a bootstrappable pyproject.toml that can be easily used to generate new environments.
3. Each repository will be responsible to to create metrics, output a suggestion and push the new session to slims
4. The code in a repository will follow a template structure with the following interface:
   • The launcher will call an entry point from the curriculum, by default "curriculum -run --path=path_to_session --[opt]=value"
   • The sole input to the curriculum shall be the data directory that resulted from the session.
   • The curriculum will return (ideally via stdout) a serialized version of the new suggestion and of the calculated metrics to be appended to the aind-data-schema. If the process errors, we shall raise an exception and skip the curriculum step on the launcher side
   • Users are allowed to create new assets in the data directory folder
5. Curriculums will be added to the task repository (e.g. Aind.Behavior.VrForaging) via submodules. In order to update a curriculum, users must make a PR to the repository and have it reviewed. This step ensures that:
   • All code is properly version controlled
   • Easy way to find available curriculums
   • Makes it easy to ensure that everything is running stably at the rig
6. Once control is returned to the launcher, watchod will be triggered and sci comp schemas eventually staged in docdb