Add no_std support

[XAMPPRocky]

This is a renewed version of #50 for rust-lang/#39503.

cc @Mark-Simulacrum

[XAMPPRocky]

I've fixed the problems on linux. The failures in the CI seem unrelated to the PR.

[alexcrichton]

Thanks for the PR! I fear though that the strategy of sprinkling feature = "std" wherever necessary makes the code pretty unmaintainable and harder to read. I think there's perhaps some simple fixes though?

• The entire capture module should probably be removed in no_std mode, only the bare-bones stack-based API is probably all we need to provide.
• With locking not being possible, I think that some APIs need to be unsafe? I believe both libbacktrace and windows need to be synchronized to work safely
• I think that we'll maybe want to pick a different abstraction for filenames if Path isn't available, because almost all platforms still want a file name one way or another
• I think we still want Debug impls in no_std mode?
• Getting the name of a symbol is pretty important, so I think we'll want a solution for that in no_std mode as well

[XAMPPRocky]

@alexcrichton Thanks for the feedback, I currently have a in development version that addresses most of this. However I wanted to ask you what kind of abstraction were you thinking for the Path alternatives? We could have it return a &str? We could make this easily maintable by having a type BacktracePath = Path; on std and on core we have type BacktracePath<'a> = &'a str;?

[alexcrichton]

I think Windows may be a stickler where the information is actually &[u16] instead of &[u8], so we can probably just add a custom enum that's something like ByteOrWideString and has convenience accessors when std is enabled

[XAMPPRocky]

@alexcrichton Okay, I've updated the PR with your feedback. Please let know if there's anything else required!

[alexcrichton]

Thanks! I think CI is still broken though?

[XAMPPRocky]

@alexcrichton Okay, I fixed everything wrong with the CI, and made changes in respect to your feedback. Let me know if there is anything else!

[alexcrichton]

I've been working through this but unfortunately ran out of time for the near future. I don't mind picking this up from here, but some things I've noticed are:

• There's a number of warnings across various platforms to squelch
• Windows and --no-default-features is having issues, needs to unconditionally depend on winapi, and needs to remove "std" from winapi. Additionally need to be added to CI
• Windows uses Box::new but can use #[repr(align)] instead now
• APIs need to be documented now that they require the std feature
• resolve and trace should both be implemented in terms of *_unsynchronized
• Overall the BytesOrWideString is still somewhat uncomfortable on Windows, but I think it's workable still? We won't want to shut off things on windows entirely, we'll want some sort of fallback that still works. I think this means some utf-16 decoder may be needed
• The printing logic for symbol names still needs to work the same way in/out of std

[XAMPPRocky]

@alexcrichton I don't mind working on it. in relation to resolve and trace, resolve can be implemented with resolve_unsynchronizedbut trace causes smoke_test_frames to fail. Would you know why that is, and how to solve that?

[alexcrichton]

@Aaronepower oh that's probably because the test is quite brittle and some constants in there need to change, although if that doesn't get it passing I can help dig in too

[alexcrichton]

Ok I've pushed up all the changes that I think I'd like to see, now waiting on CI