Moving features to core

[nacaclanga]

Great work you are doing. I noticed that in this branch, you do two things simultaniously:

1. Moving stuff from std to core or alloc
2. Replacing stuff from std with equivalent stuff from rustix.

I am not sure if it really beneficial to persue both of these in the same commit. Maybe it would be better to propose all change of target 1 in seperate commits (in case there are none allready) and restrict to only target 2 here. The only disadvantage I see is, that one must ensure that rustix types should not be exposed to the end user directly, to ensure that we can savely substitute them by their core equivalent if it gets created.

[sunfishcode]

Thanks! Yes, I've been attempting to keep the changes factored into independent patches, so hopefully it'll be straightforward to split them apart as needed. For example, I recently learned of rust-lang # 78802, in which the work to move several of the things we need into core is already underway. In theory, once that's ready we can just drop 26ab235e542390969d676d00f30f2a989125ef92.

[nacaclanga]

Yes. However I still see two issues with rust-lang # 78802: A) The way you currently implement the IpAddr and co. types is plattform depended. If they are actually moved into core, I am almost certain, that they will be plattform independendly defined. B) This can only be merged after rust-lang#78802 is.
In my opinion the way forward would be to keep the IpAddr and co. types defined in rustix separate from the ones defined in std/core. In std's public API, only the ones already defined would show up. When you std code wants to call a rustix function, it needs to convert its own types into the rustix version first.
Once rust-lang#78802 is merged, rustix can decide whether they want to keep using types optimized to each platform or internally convert to core's platform independent layout.