Refactor and document dataInjections

[Racer159]

Describe what should be investigated or refactored

Currently dataInjections make a few assumptions that make them less flexible than they could be and that are not documented leading to confusion among users.

I would propose dropping the current data injection marker requirement and instead push users to back the container's target directory with a PV rather than trying to detect the "generation" of a pod to handle the injection. In the current code, if a pod is recycled the injected data would be lost anyway without a PV leading to a brittle configuration - requiring a PV would guide users towards a better practice and would allow data injection to function more generically across components and packages.

The data injection marker itself should still be retained though as a way for an initContainer to determine if it was done receiving data however - and this should also be documented clearly.

Links to any relevant code

https://github.com/defenseunicorns/zarf/blob/main/src/pkg/cluster/data.go#L45

Additional context

This has come up from the community and d 🦄 users as a point of confusion and reason to not use data injections in the past.