Unnecessary use of Guava in StatusCheck

[jglick]

Noticed a nonfatal error in a functional test in workflow-durable-task-step while restarting a controller using an inbound agent in push mode (jenkinsci/workflow-durable-task-step-plugin#323):

INFO	hudson.lifecycle.Lifecycle#onStatusUpdate: Jenkins stopped
jenkins.util.ErrorLoggingScheduledThreadPoolExecutor afterExecute
WARNING: failure in task not wrapped in SafeTimerTask
java.lang.NoClassDefFoundError: com/google/common/io/Files
	at org.jenkinsci.plugins.durabletask.FileMonitoringTask$FileMonitoringController$StatusCheck.invoke(FileMonitoringTask.java:388)
	at org.jenkinsci.plugins.durabletask.FileMonitoringTask$FileMonitoringController$StatusCheck.invoke(FileMonitoringTask.java:382)
	at hudson.FilePath.act(FilePath.java:1192)
	at hudson.FilePath.act(FilePath.java:1175)
	at org.jenkinsci.plugins.durabletask.FileMonitoringTask$FileMonitoringController.exitStatus(FileMonitoringTask.java:418)
	at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.exitStatus(BourneShellScript.java:301)
	at org.jenkinsci.plugins.durabletask.FileMonitoringTask$Watcher.run(FileMonitoringTask.java:603)
	at …
Caused by: java.lang.ClassNotFoundException: com.google.common.io.Files
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:476)
	at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:220)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 14 more

Looks like this StatusCheck forced Guava to be loaded in the agent for the first time, which failed because the connection was closing.

Removing use of Guava in favor of Java Platform methods, and simplifying implementation somewhat (while trying not to regress #80 or similar—hard to know).