Introduce additional matchers to TimeZoneUsage rule

[chamil-prabodha]

The OffsetDateTime, OffsetTime and ZonedDateTime classes implement methods such as now(), now(Clock clock), now(ZoneId zone) which either rely on the system clock or retrieve the time zone in the clock variable. The calls to the aforementioned methods should be avoided as per the definition of TimeZoneUsage rule.

This PR detects the usage of such violations and produces warnings during the compilation.

[chamil-prabodha]

Suggested commit message:

Introduce additional matchers to `TimeZoneUsage` check (#311)

Add matchers for `OffsetDateTime`, `OffsetTime` and `ZonedDateTime` classes.

[nathankooij]

I think it looks good in principle, but I worry about the migration effort that this will put on the WMS team, which will hurt adoption. What is the expected migration path for them, and can we help ease their pain? (They are big users of OffsetDateTime.now(...).)

[rickie]

Added a commit with some unrelated cleanup. Nice improvements @chamil-prabodha !

Created an alternative suggested commit message:

Have `TimeZoneUsage` check flag `{OffsetDate,Offset,ZonedDate}Time#now` (#311)

[Stephan202]

Changes LGTM.

W.r.t. OffsetDateTime.now(clock) usages: Internally we use UTC clocks, so I think that would become clock.instant().atOffset(UTC), which isn't that bad.