Fix Netkan timezones again

[HebaruSan]

This is a spiritual successor to #3157.

Problem

A Discord user and I saw the same issue described in #3157: netkan.exe repeatedly purging and re-downloading a cache entry that it thought it was stale. The file was uploaded less than an hour previously, and I'm in the western hemisphere.

Cause

Here updatedToken will be a JToken object representing the (correct) value of release_date in the .ckan file, which includes timezone info:

CKAN/Netkan/Model/Metadata.cs

Lines 112 to 118 in 90fdf7a

	JToken updatedToken;
	DateTime t;
	if (json.TryGetValue(UpdatedPropertyName, out updatedToken)
	&& DateTime.TryParse(updatedToken.ToString(), out t))
	{
	RemoteTimestamp = t.ToUniversalTime();
	}

To convert it to a DateTime, we:

1. Cast it to a string, which internally results in something like 12/21/2020 7:53:07 PM, lacking timezone info
2. Parse that string into a DateTime, which also lacks timezone info
3. Call ToUniversalTime(), which adds (subtracts?) the local timezone offset to the timestamp, which for me was moving it into the future, which meant that my local file was always too old to result in a cache hit

Changes

Now we cast directly from JToken to DateTime, which is allowed and preserves the timezone info:

• https://www.newtonsoft.com/json/help/html/M_Newtonsoft_Json_Linq_JToken_op_Explicit_20.htm

This fixed the mistaken cache purging in my testing.

[DasSkelett]

The Problem with Time & Timezones - Computerphile (Tom Scott)

Looking good code-wise, I'll give it a quick test run.

[HebaruSan]

And we're not even trying to do any of the complicated stuff in that video, we're just trying to load a UTC timestamp and keep it in UTC all the way through the program.

[DasSkelett]

Found a bug of #3223 while testing this (will note over there), but this PR on itself works fine 🎉 😄
Until someone on the ISS, whose clocks run on Astronomical Time comes by, at least.