Separate the NeuroMechFly class into an environment, fly class and potential other classes

[stimpfli]

Refactor the code keeping in mind that the environment could accommodate:

• More flies
• Other features than an arene (e.g ball, ...)

[sibocw]

As we discussed today:

• Let's have a Simulation class which is the main MDP environment (ie. implements gym.Env)
• Simulation contains an Arena object and one or more NeuroMechFly instances
• The dm_control.mjcf.physics.Physics instance will belong to Simulation instead of NeuroMechFly

The advantages are:

• If we need to modify the arena (eg. change the object position in an arena with a moving object), we don't need to do it strangely by accessing the arena through the fly.
• A cleaner interface for simulations with multiple flies (useful for social behaviors).

Questions:

• Do the NeuroMechFly and Arena need an inverse link to the Simulation that they belong to? I don't like this because it makes the UML diagram messy and recurrent, but it might be necessary if we want to have an interface for the user to do things with the arena or the flies that would require access to the Physics instance.

@tkclam: Look at Barbara and Florian's semester project, they've done something like this already.

I don't think this is urgent but I do think it's better to do this now than later, as this is a major API change. If maintaining backward compatibility is too complicated, we can also forget about it and make a non-backward-compatible version as the paper is updated for revision. I think it's a reasonable thing to do.

[sibocw]

This is being implemented in https://github.com/NeLy-EPFL/flygym/tree/new-api