Update layer_by_layer.adoc to clarify PAC limitations

[natevw]

proposed fix for #4226, re. #4226 (comment)

[i509VCB]

I still think it is valuable to emphasize a pac may result in unsafe code if you program the hardware incorrectly (DMA is the primary example of this). lulf did mention this in the linked issue.

Technically I think pac crates should be 100% unsafe, but that would only result in a lot of extra unsafe {} blocks with no real benefit unless you explain every single instance of unsafe access.

[workingjubilee]

Technically I think pac crates should be 100% unsafe, but that would only result in a lot of extra unsafe {} blocks with no real benefit unless you explain every single instance of unsafe access.

Constructing a type unsafely... even a ZST that can be created anywhere... that then exposes the API of the crate using safe functions would allow you to contain the unsafe to a single invocation. The ergonomics would still take a small hit from occasionally having to will that ZST into existence using a line of code, but I think "you have to use unsafe code to cause memory corruption" is a worthwhile property to preserve in Rust programs.

Probably best to create a separate issue if we want to discuss that idea further, though.