feat: refactor model classes to prefer to java.time types

[BenWhitehead]

What's been added

Fields which map to apiary DateTime RFC 3339 fields will now also have
a preferred java.time.OffsetDateTime getter & setter.

Fields which map to apiary long to represent a duration in epoch millis
will no also have a preferred java.time.Duration getter & setter.

All new methods currently have the name of the corresponding java.time
type appended to the property name.

Refactor Long -> java.time.OffsetDateTime

• BlobInfo#createTime
• BlobInfo#customTime
• BlobInfo#deleteTime
• BlobInfo#retentionExpirationTime
• BlobInfo#timeStorageClassUpdated
• BlobInfo#updateTime
• Blob#createTime
• Blob#customTime
• Blob#deleteTime
• Blob#retentionExpirationTime
• Blob#timeStorageClassUpdated
• Blob#updateTime
• BucketInfo.CreatedBeforeDeleteRule
• BucketInfo.DeleteRule
• BucketInfo.IsLiveDeleteRule
• BucketInfo.NumNewerVersionsDeleteRule
• BucketInfo.RawDeleteRule
• BucketInfo#createTime
• BucketInfo#updateTime
• Bucket#createTime
• Bucket#updateTime
• Bucket#retentionEffectiveTime
• HmacKey.HmacKeyMetadata#createTime
• HmacKey.HmacKeyMetadata#updateTime

Refactor Long -> java.time.Duration

• BucketInfo#retentionPeriod
• Bucket#retentionPeriod

Deprecation of existing methods

All existing "Long" based methods have been marked as @Deprecated
and had their javadocs updated to point to the new preferred
corresponding java.time method.

When the existing "Long" based methods are removed, the corresponding
java.time method will replace it at which point the java.time suffix
methods will be deprecated for later cleanup.

All existing "Long" based methods take care of performing the necessary
conversion to the respective java.time type and will continue to work
until their removal.

Why append the java.time type as a suffix?

1. Getters can't be overloaded, so we already need something to disambiguate
   which type should be returned.
2. For setters: we theoretically could overload since we have different
   method arguments, however, if a customer is already passing null as the
   method argument we've now created an ambiguity as to which method to
   invoke. By suffixing the setters as well, we avoid creating this possible
   ambiguity.

Part 2 of #1388

[sydney-munro]

LGTM just a small nit.

[sydney-munro]

nit: inconsistencies between style.
before you do

Builder setUpdateTime(Long updateTime) {
      this.updateTime = millisOffsetDateTimeCodec.encode(updateTime);
      return this;
    }

vs calling the offset method in the deprecated old method.

[BenWhitehead]

Yeah, I agree this feels bad.

The method where the new one, calls the existing deprecated method is there to provide binary compatibility on the base builder. For reasons lost to time, the base builder is all public and someone theoretically could have extended it. In our implementations, I then do the proper order of the deprecated method calling the new method.