Add stacktrace to ASSERTs

[ravenblackx]

Commit Message: Add stacktrace to ASSERTs
Additional Description: Before this change, ASSERTs provoke a stacktrace, but it is always the useless two-line stacktrace

#0: sigHandler()
#1: restore_rt

as demonstrated by the test case added in this PR not passing before the change.
It's a bit odd that after this change there will be two stacktraces output on assert, but at least one of them will be useful.

Risk Level: Minimal, it's just output from asserts so if it does anything it's during a crash anyway.
Testing: Added a test case, and used to debug my production issue which I couldn't with the original version.
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a

[yanavlasov]

Looks like legit failures.

/wait

[ravenblackx]

Looks like I'm not able to make that function call consistently be not-inlined enough to show up in an opt build's stack trace. Not sure if I could reasonably do "only test that in non-opt builds" somehow? Could potentially force the function to stay a function by putting it into a different compilation unit, but that seems like overkill.

[ravenblackx]

Also baffling, @ggreenway says that a RELEASE_ASSERT produces a useful stack trace for them (without this change); in my build environment, a null pointer exception provokes a useable stack trace, an externally-provoked SIGABRT provokes a useable stack trace, an IS_ENVOY_BUG provokes a useable stack trace, but for some reason ASSERT or RELEASE_ASSERT consistently gives me only the useless two-liner.

Regardless of that though, this change seems like it's useful in general because a stack trace on an ASSERT triggered by a test would be useful, and as this test shows, we don't get one before this change.

[yanavlasov]

You can try adding ifdef DEBUG and exit the test if it is not present

/wait

[ravenblackx]

That worked for gcc, coverage and asan, but looks like msan is still inlining it.