Memory leak if define class name and use it inside the same script

[alexeykorshak]

Godot version:
3.1.1

OS/device including version:
Windows 10 - 64 bit

Issue description:
If define script with class_name <CLASS_NAME> and use this CLASS_NAME as static type then error "ObjectDB Instances still exist!" appears after closing of a game

Steps to reproduce:
Create new project
Create scene with one node
Attach script below to node:

extends Node2D

class_name MemoryLeakExample

var variable: MemoryLeakExample

Export scene and run with -v flag.
Close the project
The following errors can be found in the console:

ERROR: ~List: Condition ' _first != __null ' is true.
   At: ./core/self_list.h:111
ERROR: ~List: Condition ' _first != __null ' is true.
   At: ./core/self_list.h:111
WARNING: cleanup: ObjectDB Instances still exist!
     At: core/object.cpp:2095
Leaked instance: GDScriptNativeClass:656
Leaked instance: GDScript:1092 - Resource name:  Path: res://MemoryLeak.gd
ERROR: clear: Resources Still in use at Exit!
   At: core/resource.cpp:425
Orphan StringName: Node2D
Orphan StringName: variable
Orphan StringName: GDScriptNativeClass
Orphan StringName: res://MemoryLeak.gd
Orphan StringName: _init
Orphan StringName: GDScript
StringName: 6 unclaimed string names at exit.

If this is not allowed it would be nice if IDE at least prints error and doesn't allow to compile such code.

Minimal reproduction project:
MemoryLeak.zip

[YeldhamDev]

CC @bojidar-bg @vnen

[alexeykorshak]

Usage of declared class name for method arguments or return type inside the same class also leads to this issue:

extends Node2D

class_name MemoryLeakExample

func test(arg: MemoryLeakExample):
    pass
    
func test2() -> MemoryLeakExample:
    return null

[rafallus]

Same happens with Godot 3.2 latest build 3bd49da under Windows 10 - 64 bit

[CowThing]

I noticed the same issue. It also happens with internal classes that reference themselves.

extends Reference

class MyClass:
	
	func test() -> MyClass: # Leak
		return null

[bojidar-bg]

Going to close this as a duplicate of #27136, in an attempt to cut down on the amount of GDScript circular reference issues open.