Allow replicationRetry to be configured with a time-unit suffix

remote.NAME.replicationRetry was parsed as a bare integer and scheduled
in TimeUnit.MINUTES, so the smallest non-zero offline-retry backoff an
admin could configure was a full minute. That minutes-only quantum also
prevents ReplicationIT from driving a sub-minute retry, which keeps its
two new-project cases slow.

Parse replicationRetry with ConfigUtil.getTimeUnit and schedule the
retry in seconds. A value without a unit keeps its historical meaning of
minutes, so existing configurations are unchanged, while a value with a
time-unit suffix -- e.g. "30 s", "90 s" or "2 m" -- is honoured as
written. getRetryDelay() now returns seconds, matching the
RemoteConfiguration javadoc that already documented it as such, and both
reschedule sites in Destination (the direct retry and the failover
replacement) schedule in TimeUnit.SECONDS instead of TimeUnit.MINUTES.
This follows the httpd.maxwait precedent in gerrit-core, which likewise
defaults a bare number to minutes and accepts an optional unit suffix.

Use the new option to speed up the two new-project cases
(shouldReplicateNewProjectWithoutRefLog and
shouldCreateNewProjectWithRefLog): their first ref-push finds the
replica repository missing, PushOne#createRepository creates it, and
the push is rescheduled as REPOSITORY_MISSING, which waited the
one-minute replicationRetry. They now set replicationRetry to
TEST_REPLICATION_RETRY_SECONDS (1s) so the missing-repository
retry fires in a second, with TEST_NEW_PROJECT_TIMEOUT tightened
to match. The shared TEST_REPLICATION_RETRY_MINUTES is left
untouched so tests that rely on the real one-minute retry (e.g.
ReplicationStorageIT) keep their timing. The two cases drop from
~60s to ~4s; ReplicationIT drops from ~173s to ~61s, all 26 green.

Release-Notes: remote.NAME.replicationRetry now accepts an optional time-unit suffix (e.g. "30 s"); a bare number still means minutes.
Change-Id: I54f8e3d48d20568b2858abde1e1b06f35bf27841