[Request]: Enhanced error reporting.

### Feature or enhancement request details

We have #642 open for ensuring that errors/progress information go to stderr and only true command output goes to stdout.

Our presentation of errors today leaves a bit to be desired, however.

ContainerizationError is not well suited for presenting errors to the user. We need to define error types in container that:

- Presents error messages in clear, user-intuitive language.
- Covers common resource management error cases, with a field for the related resource identifier.
- Covers common runtime lifecycle and process management errors.
- Allows creation of composite errors for indicating partial failures on collection operations.
- Allows clients and tests to differentiate errors without resorting to parsing error messages.
- CLI returns differentiated exit status values for errors.

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Start by reviewing ContainerizationError and the CLI error-handling path, then read issue #642 for the related stdout and stderr behavior. Done means defining user-intuitive, distinguishable resource and lifecycle errors, supporting composite partial-failure errors, and returning differentiated CLI exit statuses.

Written by the indexing model from the issue text.