Deprecate the "timezone" query parameter for v2 and newer end-points

As described in https://github.com/USACE/cwms-data-api/issues/556#issuecomment-1984710644 the "timezone" parameter is a little bit weird when used in JSONv2 and XMLv2. It basically only used as a way for the user to specify a default timezone to be used if the user didn't include timezone info in their "begin" and "end" strings.

It makes it so the user could specify
begin = 2022-01-06T00:00:00
end = 2022-01-06T12:00:00
timezone = UTC
or
begin = 2022-01-06T00:00:00
end = 2022-01-06T12:00:00
timezone = America/Los_Angeles

I think the V2 end-points sort of inherited this behavior. But its too helpful.

The V1 end-points also passed timezone into the pl/sql and the pl/sql promised to return values in the specified timezone.

The V2 end-points return data in UTC. Maybe V2 isn't always UTC but I can't think of when it isn't and if it isn't we need to document that better.

Instead of continuing to "inherit" the old behavior (in my opinion) we should force the clients to give us better inputs (timestamps with tz) and throw errors if the inputs seem weird.

Start with the v2 endpoint entry points and the discussion in issue 556, then trace how timezone, begin, and end are validated and how response timezones are defined. Done means the v2 behavior is decided and implemented consistently: timezone is deprecated or rejected, timezone-bearing timestamps are required where appropriate, and any UTC behavior is documented.