Raise error when a generator is defined in generators and generate()

[AbrilRBS]

This used to be a mistake, but no error was ever given to the user

Changelog: (Feature): Raise an error when a generator is both defined in generators attribute and instantiated in generate() method
Docs: Omit

• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.

^{Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.}

[memsharded]

Beware, it happens that the VirtualBuildEnv and VirtualRunEnv are implicit, even if they are not declared, they are called after generate().

I think that is the thing breaking the tests.

[AbrilRBS]

Yeah, I had some errors locally with integration tests that looked like remote issues, and this slipped thru the cracks when checking for real errors.

Most of the were something like this, let's discuss it tomorrow:

Example of one of the test errors I'm getting, click to expand

E           Exception: 
E           ------------------------ Command failed (unexpectedly): ------------------------
E           upload * --confirm -r default
E           ----------------------------------- Output: ------------------------------------
E           Checking which revisions exist in the remote server
E           Checking which revisions exist in the remote server
E           Preparing artifacts to upload
E           Compressing recipe...
E           Compressing package...
E           Please log in to "default" to perform this action. Execute "conan user" command.
E           Remote 'default' username: Please enter a password for "admin" account: ERROR: b"module 'jwt' has no attribute 'encode'"
E           
E           Invalid server response, check remote URL and try again. [Remote: default]```
</details>

[SSE4]

it's duplicated multiple times, maybe it makes sense to extract code to its own function?

[memsharded]

I thought that this would take just 2 lines, the if and then 1 line for the error message, not 3.
So @RubenRBS do whatever you think it is best, I am happy with either way.

[AbrilRBS]

My only issue with this is the thing we mentioned on friday that it's not obvious where to place such helper function. I've done so in tool's init, but happy to change. Thanks @SSE4 for your suggestion :)

[AbrilRBS]

I've noticed that VirtualRunEnv and VirtualBuildEnv are instantiated in lots of places just to handle some envs, even though the generator is defined in the attribute.
Maybe it would be better for the check to run in the generate() method of at least those generators, and possible the rest too?

[memsharded]

Importing a private function from another module can be a linting or style error, we might need to rename it (later, not now), and if there are concerns of being accessible for users, it should be moved to internal namespace.

[SSE4]

Importing a private function from another module can be a linting or style error, we might need to rename it (later, not now), and if there are concerns of being accessible for users, it should be moved to internal namespace.

yes, I think conan.tools is a public namespace for recipe authors. if function isn't supposed to be used in recipes, it should go to some other place. also we usually use more specific nested namespaces, like conan.tools.xxx.
leading underscore implies private function, so it's okay.

[AbrilRBS]

Thanks for your suggestion @SSE4. I ended up adding it to tools/internal as suggested