doc/uefi: improve Protocol and Device Path documentation

[phip1611]

Make the role of the high-level DevicePath wrapper more clear.

Checklist

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

[phip1611]

Hey @seijikun,
as you were working a lot with device paths recently; do you think we need more improvements to the documentation? Do you think these improvements here are sufficient?

[seijikun]

I don't remember in full detail, but:

One thing I happend to "stumble" over while developing was, implementing the scsi path_node() method (PR pending).
The raw API returned me a *DevicePathProtocol and if I remember correctly, I tried to cast that to a &DevicePathNode, which just hard-crashed (no panic, no result, just .. gone) the application at some point later. In the end, it turned out to be crashing somewhere here:

    fn deref(&self) -> &Self::Target {
        unsafe { DevicePathNode::from_ffi_ptr(self.0.as_ptr().as_ptr().cast()) }
    }

So it took me a while to understand how the API was meant to be used and what the relationship between FFiDevicePath, DevicePathProtocol and DevicePath/DevicePathNode is. Admitedly .. it's still rather hazy :D

But I think that's mostly interna - so not very interesting for users of uefi, and more for potential contributors.

Personally, I mostly use to_string() and that's easily discoverable 👌

[phip1611]

@nicholasbishop I'd like to add more about protocol interfaces being null; why can they be null and when is this valid? Can you help?