Add armv7a-vex-v5 tier three target

[max-niederman]

This adds a new tier three target with std support called armv7a-vex-v5, targeting the microcontroller used in the VEX V5 student robotics competition. This is a joint effort by the maintainers of the vexide project, which currently provides a no_std library targeting this device using a custom JSON target, and is intended to improve the UX for users of vexide or vex-rt, and anyone else writing Rust programs for VEX V5.

Tier 3 Target Policy Compliance

A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

As listed in the target docs, the following members of the vexide project are the designated target maintainers:

• @max-niederman
• @Tropix126
• @Gavin-Niederman
• @doinkythederp

Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.

armv7a-vex-v5 follows the cpu-vendor-model convention used by most tier three targets. E.g., armv76k-nintendo-3ds or armv7k-apple-watchos.

Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.

Although the VEX V5 Brain is proprietary, this target does not link to any proprietary binaries or libraries, and is based solely on publicly available information about the VEX SDK.

Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.

I understand and assent.

Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

The parts of std which are not implemented are appropriately stubbed, and there are no parts of the standard library which authors are obligated not to call.

Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

I understand and assent.

Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.

I understand and assent.

Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.)

armv7a-vex-v5 has nearly identical codegen to armv7a-none-eabihf, so this is not an issue.

If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.

I understand.