GDScript: Update get_stack(), print_stack(), and print_debug()

[dalexeev]

Initially I suggested deprecating these functions, but now I think it makes sense to have shorthands for simple scenarios. We just need to add a reference to Engine.capture_script_backtraces() for advanced scenarios.

• Remove the restriction on using these functions only in the main thread. This already works for Engine.capture_script_backtraces(), since the stack information is stored in thread_local variables.
• Update documentation. These functions and Engine.capture_script_backtraces() use the same mechanism, so the same rules apply to them.
• Add stack output to Utils.check(), see the comment.

@tool
extends EditorScript

func _run() -> void:
    var thread := Thread.new()
    thread.start(_thread_function)
    test()
    thread.wait_to_finish()

func _thread_function() -> void:
    test()

func test() -> void:
    #print_stack()
    #print(Engine.capture_script_backtraces())
    for i in 10:
        prints(i, get_stack().slice(1))

[Mickeon]

I know what you mean, but maybe it's worth being just a bit more specific, and maybe slightly less technical?
This makes me notice how rarely the three terms are used. "debug build", "editor build", "release build". I've more often seen "when running the project in [...]" and similar (basically expanding the meaning of a "build"), but it's harder to keep count of them.

Suggested change

	[b]Note:[/b] By default, backtraces are only available in editor builds and debug builds. To enable them for release builds as well, you need to enable [member ProjectSettings.debug/settings/gdscript/always_track_call_stacks].
	[b]Note:[/b] By default, this function is only available when running the project in the editor or in debug builds. To enable them for release builds, [member ProjectSettings.debug/settings/gdscript/always_track_call_stacks] must be enabled.

Mmmm...
Also applies for the other descriptions.

[dalexeev]

Borrowed from here:

godot/doc/classes/Engine.xml

Lines 12 to 21 in e37c626

	<method name="capture_script_backtraces" qualifiers="const">
	<return type="ScriptBacktrace[]" />
	<param index="0" name="include_variables" type="bool" default="false" />
	<description>
	Captures and returns backtraces from all registered script languages.
	By default, the returned [ScriptBacktrace] will only contain stack frames in editor builds and debug builds. To enable them for release builds as well, you need to enable [member ProjectSettings.debug/settings/gdscript/always_track_call_stacks].
	If [param include_variables] is [code]true[/code], the backtrace will also include the names and values of any global variables (e.g. autoload singletons) at the point of the capture, as well as local variables and class member variables at each stack frame. This will however will only be respected when running the game with a debugger attached, like when running the game from the editor. To enable it for export builds as well, you need to enable [member ProjectSettings.debug/settings/gdscript/always_track_local_variables].
	[b]Warning:[/b] When [param include_variables] is [code]true[/code], any captured variables can potentially (e.g. with GDScript backtraces) be their actual values, including any object references. This means that storing such a [ScriptBacktrace] will prevent those objects from being deallocated, so it's generally recommended not to do so.
	</description>
	</method>

By default, this function is only available

I would avoid such wording. These functions are available and work in all builds without any errors or warnings, it's just that the result differs depending on the build and project settings.