More detailed type annotations in graph visualizations

Start in htypes.py at get_type_as_string, which currently reduces parameterized types such as dict[str, MySpecialClass] to their base name. Check how the function handles typing.get_args() and verify that the resulting graph type annotation preserves nested type attributes without using fully qualified names. Done means parameterized annotations display their component types while existing simple types remain unchanged.

Is your feature request related to a problem? Please describe.
With the current graph visualization, a node with a return type of dict[str,MySpecialClass] will just have "dict" listed as type.
The conversion of the type to string seems to happen in get_type_as_string, which is currently implemented as:

def get_type_as_string(type_: Type) -> Optional[str]:
    """Get a string representation of a type.

    The logic supports the evolution of the type system between 3.8 and 3.10.
    :param type_: Any Type object. Typically the node type found at Node.type.
    :return: string representation of the type. An empty string if everything fails.
    """

    if _is_annotated_type(type_):
        type_string = get_type_as_string(typing.get_args(type_)[0])
    elif getattr(type_, "__name__", None):
        type_string = type_.__name__
    elif typing_inspect.get_origin(type_):
        base_type = typing_inspect.get_origin(type_)
        type_string = get_type_as_string(base_type)
    elif getattr(type_, "__repr__", None):
        type_string = type_.__repr__()
    else:
        type_string = None

    return type_string

In the above mentioned example this seems to fall into the second case (using__name__), which will discard the type attributes

Describe the solution you'd like
Adding

    if typing.get_args(type_):
        type_string += f"[{', '.join(get_type_as_string(arg) for arg in typing.get_args(type_))}]"

before the return seems to fix this issue for my cases.

Describe alternatives you've considered
The str() option will return fully qualified names, which might not be desired since it would make text too long. A custom version could be implemented (for example by regex replacing the module names)