Secret Scanning match logic does not work between (GHES) to (GHEC)

## Description
It seems that sometimes the way secrets are matched it captures a bit more/less of the text containing the secret as the value, which causes problems when we try to match them up to migrate the metadata.

For example in the source repo (GHES) the secret value is:
AccountName=vehordereastdevstorage;AccountKey=icsuWApIghSQcCQV/w2mLqd4MUV6o17pLjSK2VFXrP/1ACy0yT+vacorCpJQQLuh8nn/1jKRSajmnRStBaZDYw==

However, for the same code file, the secret value in the target repo (GHEC) is ONLY the actual account key:
icsuWApIghSQcCQV/w2mLqd4MUV6o17pLjSK2VFXrP/1ACy0yT+vacorCpJQQLuh8nn/1jKRSajmnRStBaZDYw==

The existing secret alert migration logic expects the secret values to be identical, and in this case it won't find a matching secret and won't migrate the alert metadata.

The automatic matching and closing of secret alerts does not work between (GHES) to (GHEC) so manual remediation is required.

Refer to prior PR’s
https://github.com/github/gh-gei/pull/948
[Secret Scanning bug fix when secret values are longer in source/target by dylan-smith · Pull Request #948 · github/gh-gei](https://github.com/github/gh-gei/pull/948)
https://github.com/github/gh-gei/pull/848
[Update SecretScanningAlertService.cs by kyle-jones · Pull Request #848 · github/gh-gei](https://github.com/github/gh-gei/pull/848)

## Reproduction Steps
Secret alerts generated out of GHES 3.4 - 3.6 and the current GHEC EMU will not match exactly and will not sync the status of the alter upon migration.