Improve the process of obtaining `known_symbols` for use in code generation

[junkmd]

target part

https://github.com/enthought/comtypes/blob/fed3de69ccc61e37187b4a219daa120a97740663/comtypes/client/_generate.py#L237-L256

from builtin __import__ to importlib.import_module

The documentation said

Programmatic importing of modules should use import_module() instead of this function.

And,

The most important difference between these two functions is that import_module() returns the specified package or module (e.g. pkg.mod), while __import__() returns the top-level package or module (e.g. pkg).

Therefore, below part will be no longer.

https://github.com/enthought/comtypes/blob/fed3de69ccc61e37187b4a219daa120a97740663/comtypes/client/_generate.py#L252-L253

Explicitly specify symbols to be imported from comtypes.foo

https://github.com/enthought/comtypes/blob/fed3de69ccc61e37187b4a219daa120a97740663/comtypes/client/_generate.py#L254-L255

Currently, all symbols in comtypes.foo are known_symbols. This could lead to accidental import symbols that are not COM objects or c-ffi.

• enthought/comtypes#330 is an example of a bug caused by this.

There will be fewer accidents if the dictionary is statically defined rather than dynamically created depending on the namespace of the module.

No more try to import comtypes._others

Since comtypes._others is a non-existent module, importing will always fail. There should be no significance of the branching within except. So, the following code should be replaced with a single line of mod = importlib.import_module(name) without any problem. https://github.com/enthought/comtypes/blob/fed3de69ccc61e37187b4a219daa120a97740663/comtypes/client/_generate.py#L246-L251