Add check for common mistake when mixing Gym/VecEnv API

[araffin]

Description

closes #1694 (and other related issues)

Motivation and Context

• I have raised an issue to propose this change (required for new features and bug fixes)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (update in the documentation)

Checklist

• I've read the CONTRIBUTION guide (required)
• I have updated the changelog accordingly (required).
• My change requires a change to the documentation.
• I have updated the tests accordingly (required for a bug fix or a new feature).
• I have updated the documentation accordingly.
• I have opened an associated PR on the SB3-Contrib repository (if necessary)
• I have opened an associated PR on the RL-Zoo3 repository (if necessary)
• I have reformatted the code using make format (required)
• I have checked the codestyle using make check-codestyle and make lint (required)
• I have ensured make pytest and make type both pass. (required)
• I have checked that the documentation builds using make doc (required)

Note: You can run most of the checks using make commit-checks.

Note: we are using a maximum length of 127 characters per line

[ernestum]

LGTM

Reading this I was asking myself:

1. Could we somehow redesign the API so that we don't have to pull out the env from the model for prediction? It is counter-intuitive like this and feels like magic happening under the hood.
2. Why do we ship our own VecEnv and don't use the gymnasium VectorEnv? Might save us some maintenance effort in the long term.

[araffin]

Could we somehow redesign the API so that we don't have to pull out the env from the model for prediction? It is counter-intuitive like this and feels like magic happening under the hood.

obs, info = env.reset()
model.predict(obs)

works ;) (see #994 (comment))

and yes predict() has a lot of sugar coating so it works in most cases.

For env with more than one env, you need to do vec_env = make_env() anyway (so you don't pull it from the model).

Why do we ship our own VecEnv and don't use the gymnasium VectorEnv? Might save us some maintenance effort in the long term.

This question has come up several times.
To quote #229:
"those objects are critical to SB3 and Gym is not reliable enough for us to use them"

For the full story, Gym VecEnv were broken for some time and will be completely changed in the upcoming version: Farama-Foundation/Gymnasium#32 (comment)

VecEnv are what makes SB3 backward compatible with SB3 1.x and we also use custom functions like is_wrapped() and others.