FEAT: render `metadata.lifecycles`

**:mega: please discuss the options and expectations in the comments below**

----

## Is your feature request related to a problem? Please describe.

CycloneDX spec 1.5 brought `metadata.lifecycles`, with allowes to describe the ALM stage when the SBOM was created. see

one case, as @nscuro pointed out:
CLI switch `--use-lockfile-only` causes not to inspect any evidence of actually installed packages, but use the lockfile instead. the lockfile be outdated/ahead/modified for several reasons.
if CLI switch `--use-lockfile-only` was used, then the resulting SBOM is done in a certain pre-build stage.
this should be made clear in the resulting SBOM, by populating `metadata.lifecycles`

## Describe the solution you'd like

populate `bom.metadata.lifecycles`:
:mega: **to be discussed in the comments**, see options below.

optional: in addition, non-well-known values are accepted, and shall result in "named" stages.

see example at : https://cyclonedx.org/guides/sbom/lifecycle_phases/

### Option A -- _single_ value:
- have a CLI switch for the lifecycle:
- default value for `metadata.lifecycles` is determined as below
- if CLI switch `--use-lockfile-only` was used: `pre-build`
- else:
- if CLI switch `--omit dev` was used: `build`
- else: `post-build`

### Option B -- _multiple_ values:
- have a CLI switch for the lifecycles:
- default values for `metadata.lifecycles`: empty list
- if CLI switch `--use-lockfile-only` was used: add `pre-build` to the list
- if CLI switch `--omit dev` was used: ass `build` to the list
else: add `post-build` to the list

### Option C:
one of (A or B ), but no CLI option, only auto-added values

### Option D:
one of (A or B ), but no defaults nor auto-added values whatsoever (empty list/ omit `metadata.lifecycle` per default)

## Describe alternatives you've considered

:exclamation: to be discussed which solution to use, based on expectations of users

## Additional context

this feature is feasible since CycloneDX 1.5,
request for library: https://github.com/CycloneDX/cyclonedx-javascript-library/issues/937

For additional information about lifecycles and evidence, refer to:
- https://cyclonedx.org/guides/sbom/lifecycle_phases/
- https://cyclonedx.org/guides/sbom/evidence/

This all ties into SBOM quality, which OWASP CycloneDX defines here:
- https://cyclonedx.org/guides/sbom/bom/#sbom-quality

see the available phase descriptions:
- design = BOM produced early in the development lifecycle containing inventory of components and services that are proposed or planned to be used. The inventory may need to be procured, retrieved, or resourced prior to use.
- pre-build = BOM consisting of information obtained prior to a build process and may contain source files and development artifacts and manifests. The inventory may need to be resolved and retrieved prior to use.
- build = BOM consisting of information obtained during a build process where component inventory is available for use. The precise versions of resolved components are usually available at this time as well as the provenance of where the components were retrieved from.
- post-build = BOM consisting of information obtained after a build process has completed and the resulting components(s) are available for further analysis. Built components may exist as the result of a CI/CD process, may have been installed or deployed to a system or device, and may need to be retrieved or extracted from the system or device.
- operations = BOM produced that represents inventory that is running and operational. This may include staging or production environments and will generally encompass multiple SBOMs describing the applications and operating system, along with HBOMs describing the hardware that makes up the system. Operations Bill of Materials (OBOM) can provide full-stack inventory of runtime environments, configurations, and additional dependencies.
- discovery = BOM consisting of information observed through network discovery providing point-in-time enumeration of embedded, on-premise, and cloud-native services such as server applications, connected devices, microservices, and serverless functions.
- decommission = BOM containing inventory that will be, or has been retired from operations.