Project cloning should replicate "Last BOM import" and "Last Measurement" time stamps (at least when cloning components and alerts/analyses)

### Current Behavior

With DT 4.11 and earlier (did not try 4.12 yet), when I clone a project in UI (Add version) or REST API, there are a number of options to clone and re-assign different related aspects such as the set of components that comprised an older project revision, or vuln/policy analysis results.

Although the resulting cloned project is populated with a significant inventory of components, which might have originally been from a BOM document upload (at least as far as DT server knows about the original project instance), the `lastBomImport` timestamp and `lastBomImportFormat` original document format of such upload is absent in the clone.

A somewhat smaller loss is the absence of last measurement (vuln/policy alert analysis, if those are replicated) as at least if the project is active - it is instantly re-analyzed as a result of cloning. Still, we already have some answers copied with a timestamp of their last-known-valid date, so this should be carried over (especially if we end up not re-analyzing the clone).

This is slightly related to issue #4279 (bump in the road of same use-case development).

### Proposed Behavior

* When we clone a project and select to `includeComponents` and/or `includeServices`, replicate also the `lastBomImport` timestamp and `lastBomImportFormat` "BOM Format" information (if present)
* When we clone a project and select to `includeAuditHistory` and/or `includePolicyViolations`, replicate also the "Last Measurement" timestamp (if present)
* UPDATE: I am not sure if there is currently a counter (or other knowledge source) of how many times a BOM was uploaded into this project instance -- how many development iterations left their trail in the KPI history changes (like component/service headcounts, among other things) -- but such information should be replicated likewise.
* As I suggested in https://owasp.slack.com/archives/C6R3R32H4/p1729678695970759 it might make more sense to track it as a new column in `PROJECTMETRICS` with a copy of BOM's own UUID (I think it is a required piece of content), so also linking the project instance to an actual original document that may be checked in the artifact storage. Then every change of this field (as a BOM gets uploaded) would cause the relevant KPI snapshot to appear, and a `COUNT()` of this `PROJECT_ID` and unique BOM UUIDs would yield the count of BOMs iterated here. By side effect, it would keep timestamps of when each BOM document was uploaded (earliest time-ranged metrics entry with the new UUID).
* Replication via `includeAuditHistory` might automagically take care of cloning the data needed for "BOM upload count" in this case.
* If this does require new development, feel free to log it as a separate ticket, and keep in mind this one if there would be new "BOM upload count" fields to replicate e.g. in the project entry itself.
* BTW, I see that the table already includes a `COMPONENTS` count, but don't see a `SERVICES` one, if it matters (our project has little use for it yet, but it may be due to ignorance).

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/master/CONTRIBUTING.md#filing-issues)
- [x] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this enhancement was already requested