proposal: allow stack traces to be disabled even when not stripping debug info

[xdBronch]

the current logic to decide when to include stack tracing code is simply checking if debug info is stripped or not

zig/lib/std/debug.zig

Lines 119 to 122 in ff17b11

	if (builtin.strip_debug_info) {
	stderr.print("Unable to dump stack trace: debug info stripped\n", .{}) catch return;
	return;
	}

in most cases this is fine, its extremely convenient to just run your program and get stack traces on panics, errors, crashes, etc. its like your program is a debugger itself. but this isnt always the best, in embedded applications for example. you have to use ReleaseSmall but if you want to keep debug info it compiles in an insane amount of code for something you dont want or need. in cases this like its quite trivial to separate the debug info manually with e.g. objcopy and now you have the best of both worlds, tiny binary and stack traces by using a debugger.
i did a simple test on a program that only consisted of a blank panic in main and the binary sizes were the following

Config	Size
ReleaseSmall (stripped)	8.0K
ReleaseSmall (-fno-strip)	1.2M
ReleaseSmall (-fno-strip) + strip -s	130K
ReleaseSmall (-fno-strip, no stack traces)	526K
ReleaseSmall (-fno-strip, no stack traces) + strip -s	8K

im thinking this could be something in std_options then the checks in debug.zig can just be changed to something like if (!std.options.keep_stack_traces or builtin.strip_debug_info)

[notcancername]

In general, the concept of using "is stripped" as a setting for things to include in the binary is misleading, whether the binary will be stripped is not comptime-known.