Fix using the Long.MIN as UNSET for token create/update

The TCK tests have found that using `Long.MIN` for `TokenCreate`, `TokenUpdate`, or `CryptoUpdate` will result in a successful transaction. This is because we treat `Long.MIN` as `UNSET`.

A possible solution would be to change ExpiryMeta.autoRenewPeriod from long to Long and use null as UNSET.

**How to reproduce:**
```
(#6) Creates a token with an expiration time of -9,223,372,036,854,775,808 (int64 min) seconds
Value passed is considered the “unset” value in services, and therefore the test does not throw like it should
```

```
(#7) Updates a mutable token to an expiration time of -9,223,372,036,854,775,808 (int64 min) seconds from the current time
Value passed is considered the “unset” value in services, and therefore the test does not throw like it should
```

```
(#5) Updates the expiration time of an account to -9,223,372,036,854,775,808 (int64 min) seconds
Value passed is considered the “unset” value in services, and therefore the test does not throw like it should
```

Start with ExpiryMeta and the unset-value handling used by TokenCreate, TokenUpdate, and CryptoUpdate, then run the TCK cases described as #5, #6, and #7. Done means Long.MIN is rejected as an invalid expiration value in each create or update path instead of being accepted as UNSET.

Written by the indexing model from the issue text.