[ZEPPELIN-6483] Format HDFS modification time in GMT to match the printed label

[dev-donghwan]

What is this PR for?

In the HDFS file interpreter, listOne() appends a hard-coded GMT label to the
modification time, but listDate() formats the timestamp using the JVM default
time zone. On any server not running in UTC, the displayed value does not match
the label (e.g. a file modified at 2015-08-02 20:43 GMT is shown as
2015-08-03 05:43GMT on a KST server).

This PR sets the formatter's time zone to GMT in listDate() so the rendered
value matches the existing label.

Why format in GMT (option A) rather than keep local time and fix the label (option B):

• modificationTime is an absolute epoch value, so the time zone is only a
  display choice. Formatting in GMT keeps the output identical regardless of the
  host/JVM default zone and consistent with the label already printed.
• Showing the interpreter JVM's local time would be ambiguous in shared HDFS /
  remote-interpreter, multi-user setups ("whose local time?"), and the output
  would vary per deployment, making it harder to reproduce and test.

What type of PR is it?

Bug Fix

Todos

• - Format the modification time in GMT in listDate()
• - Add a regression test that runs under a non-UTC default zone (Asia/Seoul) and asserts the value is rendered in GMT to match the label

What is the Jira issue?

• https://issues.apache.org/jira/browse/ZEPPELIN-6483

How should this be tested?

• ./mvnw test -pl file -Dtest=HDFSFileInterpreterTest
• The new test testListDateFormatsInGmtToMatchLabel pins a known modificationTime (1438548219672 = 2015-08-02 20:43 GMT) under an Asia/Seoul default zone and asserts the output contains 2015-08-02 20:43GMT.

Screenshots (if appropriate)

N/A

Questions:

• Does the license files need to update? No
• Is there breaking changes for older versions? No — display-only change; on non-UTC servers the shown value changes, but it now correctly matches the label
• Does this needs documentation? No