[Feature]: Get-AzKeyVaultCertificate should return thumbprints for all versions

### Description of the new feature

### Feature Request

**Problem**
`Get-AzKeyVaultCertificate -IncludeVersions` only returns the thumbprint for the latest version. Older versions have blank `Thumbprint` values.

**Expected Behavior**
All versions should include their thumbprints, consistent with Azure Portal, Azure CLI (`az keyvault certificate list-versions`), and REST API.

**Why This Matters**
Automation scripts and runbooks often need to compare certificate versions. Without thumbprints, users must fetch secrets manually or switch to CLI/REST, which breaks consistency.

**Workarounds**
- Use `az keyvault certificate list-versions` (CLI).
- Use REST API with client credentials.
Both add complexity compared to staying in PowerShell.

**Request**
Enhance Az.KeyVault module so that `Get-AzKeyVaultCertificate -IncludeVersions` hydrates thumbprints for all versions.

### Proposed implementation details (optional)

### Suggested Approach
When `-IncludeVersions` is specified, `Get-AzKeyVaultCertificate` should hydrate the `Thumbprint` property for *all* versions, not just the latest. This can be achieved by:

1. **Leverage the Key Vault REST API**
- Call the `/certificates/{name}/versions` endpoint, which already returns `x5t` (base64url thumbprint) for each version.
- Map the `x5t` field to the `Thumbprint` property in the PowerShell object.

2. **Decode `x5t` into Hex**
- Convert the base64url‑encoded `x5t` into the familiar hex string format (e.g., `AB12CD34...`) that matches what the Portal shows.
- Populate the `Thumbprint` property consistently across all versions.

3. **Maintain Backward Compatibility**
- Continue returning the existing metadata (`Id`, `Version`, `Enabled`, `Created`, `Updated`).
- Ensure scripts relying on the current behaviour don’t break — only add thumbprints where they were previously missing.