chore: symmetric BN254 and ECDSA checks (#1540)

**Motivation:**

The `ECDSACertificateVerifier` does not do the same timetstamp checks as
the `BN254CertificateVerifier`. It also prevents 0 staleness period and
requires certificates to be against the latest reference timestamp

**Modifications:**

- Update storage of certificate verifiers to have a
`_referenceTimestampsSet` mapping
- Add `isReferenceTimestampSet` introspection
- Allow 0 staleness period for `ECDSACertificateVerifier`
- Update the `BN254CertificateVerifier` and `ECDSACertificateVerifier`
to have checks be in the same order against reference timestamp

**Result:**

Consistent code paths

Author: ypatil12

docs/multichain/destination/CertificateVerifier.md

@@ -81,6 +81,7 @@ Note that updating operator tables for a `referenceTimestamp` that is less than
 * Updates `_latestReferenceTimestamps[operatorSetKey]` to `referenceTimestamp`
 * Updates `_operatorSetOwners[operatorSetKey]` to `operatorSetConfig.owner`
 * Updates `_maxStalenessPeriods[operatorSetKey]` to `operatorSetConfig.maxStalenessPeriod`
+* Updates `_isReferenceTimestampSet[operatorSetKey][referenceTimestamp]` to `true`
 * Emits a `TableUpdated` event
 
 *Requirements*:
@@ -329,6 +330,7 @@ Note that updating operator tables for a `referenceTimestamp` that is less than
 * Updates `_latestReferenceTimestamps[operatorSetKey]` to `referenceTimestamp`
 * Updates `_operatorSetOwners[operatorSetKey]` to `operatorSetConfig.owner`
 * Updates `_maxStalenessPeriods[operatorSetKey]` to `operatorSetConfig.maxStalenessPeriod`
+* Updates `_isReferenceTimestampSet[operatorSetKey][referenceTimestamp]` to `true`
 * Emits a `TableUpdated` event
 
 *Requirements*: