Make finalized migration history limits configurable by outcome

Is your feature request related to a problem? Please describe:

KubeVirt currently retains a hard-coded, combined history of the five most recent finalized VirtualMachineInstanceMigration objects per VMI. Since #17707, garbage-collecting a finalized migration also removes its obsolete launcher pod: the old source pod after a successful migration, or the target pod after a failed migration.

As a result, an infrequently migrated VMI can retain a successful migration object and its obsolete source launcher pod indefinitely, until enough later migrations trigger the fixed buffer. At the same time, failed migration history is useful for troubleshooting and should often be retained longer than successful history.

Our concrete environment uses RWO-backed disks. After a successful migration, the obsolete source virt-launcher pod can continue referencing the source PVC. While that pod remains, the storage system cannot release the source-side PVC attachment and related capacity, so source-side and target-side data can continue consuming storage longer than necessary. For large volumes or storage-constrained clusters, retaining the source pod until a later migration triggers garbage collection creates meaningful capacity pressure and can affect subsequent migrations.

Our concrete use case is therefore to remove successful migration history immediately, allowing the source pod and its PVC reference to be released promptly, while retaining the five most recent failures for troubleshooting.

Describe the solution you'd like:

Add outcome-specific history limits under the existing migration configuration:

spec:
  configuration:
    migrations:
      historyLimits:
        successful: 0
        failed: 5

A zero value must be meaningful, so the configuration needs pointer-based presence semantics. When historyLimits is omitted, KubeVirt should preserve the current behavior exactly: retain the five most recent finalized migrations regardless of outcome. When it is present, successful and failed migrations should be limited independently.

This follows the model used by Kubernetes CronJobs, which expose separate successful and failed history limits. It lets operators clean up routine successful migrations promptly without losing failure diagnostics.

Describe alternatives you've considered:

• A single configurable total limit cannot express successful: 0 while retaining failed migrations.
• Changing the default to zero would break existing behavior and reduce post-migration debugging history.
• Relying on generic terminated-pod garbage collection is not deterministic and does not clean up the migration object itself.

Additional context:

The current fixed buffer was introduced in #7144 to retain debugging history. The proposed default preserves that behavior. This issue is intended to confirm the API shape and whether the change requires a VEP before the accompanying PR proceeds.