This PR adds standard library support for the VEX V5 Brain (armv7a-vex-v5 target). It is more-or-less an updated version of the library-side work done in #131530.

This was a joint effort between me, @lewisfm, @max-niederman, @Gavin-Niederman and several other members of the vexide project.

Background

VEXos is a fairly unconventional operating system, with user code running in a restricted enviornment with regards to I/O capabilities and whatnot. As such, several OS-dependent APIs are unsupported or have partial support (such as std::net, std::process, and most of std::thread). A more comprehensive list of what does or doesn't work is outlined in the updated target documentation. Despite these limitations, we believe that libstd support on this target still has value to users, especially given the popular use of this hardware for educational purposes. For some previous discussion on this matter, see this comment.

SDK Linkage

VEXos doesn't really ship with an official libc or POSIX-style platform API (and though it does port newlib, these are stubbed on top of the underlying SDK). Instead, VEX provides their own SDK for calling platform APIs. Their official SDK is kept proprietary (with public headers), though open-source implementations exist. Following the precedent of the armv6k-nintendo-3ds team's work in #95897, we've opted not to directly link libstd to any SDK with the expectation that users will provide their own - either through vex-sdk-build (which will download the official SDK from VEX), vex-sdk-jumptable (a compatible, open-source reimplementation), or potentially through linking the PROS kernel. The vex-sdk crate used in the VEXos PAL provides libc-style FFI bindings for any compatible system library, so any of these options should work fine. A functional demo project using vex-sdk-build can be found here.

Future Work

This PR implements virtually everything we are currently able to implement given the current capabilities of the platform. The exception to this is file directory enumeration, though the implementation of that is sufficiently gross enough to drive us away from supporting this officially.

Additionally, I have a working branch implementing the panic_unwind runtime for this target, which is something that would be nice to see in the future, though given the volume of compiler changes i've deemed it out-of-scope for this PR.