Add back in `imitation.envs.examples` support to scripts

[AdamGleave]

https://github.com/HumanCompatibleAI/imitation/pull/484 removes the import to imitation.envs.examples from src/imitation/scripts/__init__.py to workaround https://github.com/sphinx-doc/sphinx/issues/9069

Some options:

1. Move this example env code out of the repo. It was never a great fit for imitation anyway. Perhaps put it in a new contrib repo, or in seals.
2. Workaround the Sphinx bug, e.g. by a relative import or perhaps importing a specific function to call register() on.
3. Document an alternative way to use the example environments. I think something like env_name=imitation.envs.examples:imitation/Random-v0 might just work? (gym.make has some magic to import modules.)

[Rocamonde]

If we decide to keep the code, we probably should change the way we register the packages. Having module-level code that executes when it's imported is generally not a good idea for libraries (vs. frameworks). Could the user not manually call a register function if they want to use this? (maybe I'm wrong and it's how Gym is supposed to work)

[AdamGleave]

This is fairly standard practice for Gym, e.g. this happens in Gym itself and roboschool.

Of course, standard practice is not necessarily the same as good practice. The main reasons to avoid module-level code that I'm aware of are performance and possible unintended side-effects. Performance overhead should be negligible, gym.register does not do much (just updates a dict). Side-effects are contained as things are only registered under the imitation/ namespace.

The most compelling reason I can see for moving it into a manual register function is just that it's more explicit / less magical. Already we have the issue we have to do import imitation.envs.example # noqa: F841 because it's an unused import. If we added an extra line to explicitly register it, that problem would go away.

Overall don't have a strong preference here either way.