Add getAsyncStackTrace API for a shorter async stacktrace

[nitely]

Port of nim-lang/Nim#24563

Only differences:

• I tried avoiding strutils hard dependency,
• Added getAsyncStackTrace

It still injects the stack trace into the error msg, but at least that's behind a flag in Chronos, not sure in what case it's needed.

[nitely]

Issues:

• libbacktrace tests: the stack trace contains "unitest2.nim" file lines that point to PreMain, PreMainInner, main internal Nim functions for whatever reason. If we just run testasyncstacktrace directly those don't appear, but still the traceback is not as accurate (adds extra line traces pointing to empty lines, or lines which are not func calls). In Nim 1.6 the function names are the C mangled ones.
• In Nim 2.0 some file lines are excpt.nim, this seem to have been fixed in Nim 2.2. It can be reproduced with the example in Closure iterator wrong line info traceback under ORC nim-lang/Nim#24670 (affects refc too in this case).

The tests pass in linux-i386 because the libbacktrace test is skipped.

[arnetheduck]

hm, what's the use case (outside of tests) for having this public? ie longer term, it feels like we should be working towards an abstract stack trace and not a string

[nitely]

API parity with getStackTrace. As a end-user you usually want a string. This could be implemented as $getAsyncStackTraceEntries(ex) or something else, though.