Thread priority + affinity  #24

Regarding the unsupported functionality, I'm still of the opinion that getting any kind of threading support would be necessary, as it doesn't really seem fair to release ctru-rswith halfbaked dev-only features, like std-threads.

Originally posted by @Meziu in rust3ds/ctru-rs#97 (comment)

I wasn't sure where else to make an issue but I thought this repo seemed sort of sensible to track progress on the upstream threads proposal and related changes.

It will probably take a little while, but I plan to revisit the original thread proposal with the Rust team and see if we can come to some kind of middle ground that doesn't result in implementing a huge API surface in std just to support our platform.

As a brief summary of what's happened:

• Since long ago, thread priority has been requested in std: Expose thread/task priorities rust-lang/rfcs#819
• There are some third party crates for this, which maybe we should consider looking into (perhaps that is enough for our use case if we can make it work?
  • https://github.com/vityafx/thread-priority
  • https://github.com/Elzair/core_affinity_rs
• @AzureMarker opened a PR to enable full blown threads in std: std::thread support for the Nintendo 3DS rust-lang/rust#98514
• and a proposal for a new Builder API, which has had some discussion back and forth Add Special Thread Builder Functions for the Nintendo 3DS rust-lang/libs-team#71
• We also had some discussion on Zulip about the proposal, which has kind of gone back and forth
• I took a stab at implementing the proposal in Partially implement thread scheduling attributes API proposal rust-lang/rust#101222 but I wasn't totally convinced it was the right option overall.

At this point, this is my rough plan:

1. Do more research on the affinity and priority crates I mentioned above. If it's not hard to add the support we are looking for via those, maybe we can delay the std changes and just rely on them instead
2. If std still seems like a better option, rewrite the API proposal to be more generic (less 3DS-focused) and address some of the discussion concerns that have come up. I will probably end up mentioning the above crates as prior art in this space too.
3. Submit the proposal, try to get some final feedback, and implement it.
4. Add necessary libc APIs to implement new affinity APIs for std
5. Assuming all the above goes well, adjust ctru-rs examples and features to match the new std API.

Phew! This has been a long time coming so hopefully we can finally put it to rest somewhere.
Also let me know if you think this issue makes more sense to live on ctru-rs and I can transfer, it's kind of broad so I wasn't sure the best place to put it.