Add type hints according to PEP 484 and PEP 604

[TonyCrane]

Add type hints according to PEP 484, PEP 526 and PEP 604

Motivation

The motivation for this is to allow the IDE (language server) to better analyze the code and give type hints like:

And this also provides convenience for writing API documentation in the next step

Changes

I manually wrote type annotations for almost all class methods and functions following these PEP standards.
However, due to the dynamic addition of attributes using CONFIG and digest_config, the types of some attribute values ​​cannot be annotated and therefore the whole module cannot be checked with static type checkers such as mypy. So this annotation is exactly like a comment.

And it's worth mentioning that in this pull request, I upgraded the python version available for ManimGL to python 3.7 and above (i.e. python 3.6 is no longer supported). Because the type annotation system has been relatively complete since 3.7, and numpy no longer supports 3.6 since 1.20 (the numpy.typing submodule has only been added since version 1.20)
I'm not sure if it's worth giving up on 3.6, but maybe that's a general trend.

Because the changes in this PR are almost type annotations, except for some additions of import, it will not affect the normal usage (python will not check whether the variable type satisfies the annotation at runtime)

By the way, in this pull request, I also changed the order of imports according to the PEP 8 (that is, from __future__ import first, then an empty line for built-in modules, an empty line for third-party modules, and an empty line for local modules)

Progress

• manimlib.utils
• manimlib.camera
• manimlib.mobject
  • manimlib.mobject.mobject
  • manimlib.mobject.types
  • manimlib.mobject.svg
• manimlib.animation
• manimlib.event_handler
• manimlib.scene
• manimlib.shader_wrapper
• manimlib.window

[TonyCrane]

Wait for #1745

[TonyCrane]

I think this pull request needs more time to check, because it changes too much.
So any thoughts now? @3b1b

[3b1b]

This is definitely a welcome push in the right direction. I can block out some time a bit later this week to give it a more thorough look.

You mention issues associated with the current "digest_config" usage. At some point, it would be worth getting rid of that practice entirely, and to instead put all the variables current in a CONFIG dict into the init args, like normal python programmers :).

[YishiMichael]

I'd recommend that methods implemented in base classes and then overridden should keep input and output types maintained. As an example, some methods concerned with Mobject don't return self, while they do in an inherited class, which should be unified.