Evaluate, Discuss + Document role of "alloc" feature in Crate

[phip1611]

As pointed out in #1297 (comment), we should discuss our strategy regarding the alloc feature and its priority when creating user API. This should also be documented, once we discussed and agreed on a strategy.

TL;DR: Should we provide interfaces primarily like A, B, or C.

• A: fn get_data(&self) -> Result<Vec<T>> which is feature-gated
• B: fn get_data(&self, buf: &mut T) -> Result<()>
• C: Both where either A or B is prefixed/suffixed, such as _in_buffer or _owned

[phip1611]

So far, the applied approach is unspoken and was never really discussed. "We just did it somehow", mostly. From my point of view, it was a 66.6% prefer non-alloc and a 33.3% do as you like which usually defaults to alloc > non-alloc.

[nicholasbishop]

Making a note from #1528: we also have several types for data allocated internally with UEFI pool memory: PoolString, PoolDevicePath, PoolDevicePathNode`. That avoids extra memory allocations for some code, but unclear that the extra API surface is worth that optimization.

[phip1611]

I think we can close this. Reopen if necessary.

TL;DR: Make it alloc-free where easily doable. Otherwise, utilize alloc to build nice abstractions