uefi-raw: improve convenience of net types

[phip1611]

This prepares my vision for #1575, a split-out from #1645.

This adds much more convenience to the network types in uefi-raw, better integrating them with core::net types but also "typical" workflows. This "higher-level" logic is still low-level enough that I think it is perfectly fine to keep it. It will also not hinder Rust-based UEFI implementations.

Steps to Undraft

• merge and rebase onto uefi-raw: move types to net module #1747
• merge and rebase onto uefi-raw: various small net improvements #1748

Checklist

• Sensible git history (for example, squash "typo" or "fix" commits). See the Rewriting History guide for help.
• Update the changelog (if necessary)

[phip1611]

For the record. Starting Friday, I'll be on vacation until July 30th. My plan is to program-detox for the whole period 😀 Restarting the work afterwards

[phip1611]

I'm unsure how I could fix the rustdoc error best. I want the documentation of the net module to be publicly available (it is a clear value-add), but earlier you suggested exporting its exports in a flat way, i.e., directly from the top-level.

However: making the module public allows to import the same types from uefi_raw::Type and uefi_raw::net::Type, which is not ideal. Perhaps we should export all net::* types also publicly?

[nicholasbishop]

What if we removed the module doc and instead added this information to the individual types? The module doc is basically saying "you can convert between core::net types and uefi_raw net type". E.g. for Ipv4Address it could be something like:

/// An IPv4 internet protocol address.
///
/// This type can be converted to and from [`core::net::Ipv4Addr`] using the [`From`] trait.

[phip1611]

What if we removed the module doc and instead added this information to the individual types?

Yeah, good idea, why not :) What do you think about the latest state?

[nicholasbishop]

Generally looks good, but I haven't reviewed the details yet. Could you open a PR that just does the copy-paste move of stuff to a new module first? That should be very quick to review and merge, and then it won't get mixed in with the other changes. (I realize it's already broken down that way by commit, but there are still a lot of changes in commit 870aced that I would like to review more thoroughly, and it'll be easier for me if the module-move has already been merged.)

[phip1611]

should be much easier to review now