Untangle package imports

[phillebaba]

Describe what should be investigated or refactored

The current package structure causes a lot of cyclical import errors when the smallest change is made. From my perspective this is caused by keeping data types and logic in separate packages while also creating very large packages that do multiple things. Ownership of data types is not clear causing logic to be spit into separate packages.

The main culprit is the types package which contains a lot of data types related to ZarfState but also option parameters for the packager. There is value in defining structs that should have a stable API but these should not be mixed with other data types. We need to better understand which types can be updated because they are only used in memory and which need to be static because they are encoded and stored in files.

At the same time we need to understand which packages we are exporting for use as a library and which packages are for internal use only. To resolve future issues we will need to keep the exported packages stable. Right now we have not documented what the plan is at all.

A few suggestions for what we should do.

### Tasks
- [ ] Move user facing structs to a versioned api package.
- [ ] Move command line options structs out of types.
- [ ] Move data types used in single packages to their specific packages.
- [ ] Split large packages into smaller single purpose packages to reduce risk of circular imports.

Links to any relevant code

https://github.com/defenseunicorns/zarf/blob/main/src/types/packager.go
https://github.com/defenseunicorns/zarf/blob/main/src/types/runtime.go

Additional context

N/A