FileChangedReloadingStrategy should support reloading of rolled-back (older timestamp) files

Currently the FileChangedReloadingStrategy only reloads when the timestamp of the file on the filesystem is newer than the timestamp it had when it was last loaded.

This may not be the expected behaviour when, for example, an administrator makes a backup copy of the original configuration file before making changes. If the administrator wants to roll back to the original configuration, he may expect that copying/renaming the backup back to the original name, would cause the original configuration to take effect again.

Another example where the current behaviour is problematic is when using a Deploy System (like we do at my company). We expect to be able to roll-back to a previous configuration by simply redeploying the Config artifact, but because the timestamps reflect when the Config artifact was built (not when it was deployed), this roll-back will not work.

The current behaviour could be kept as the default, simply adding setReloadOnRollback() or similarly named method to change the behaviour to reload when the timestamp is either older or newer (i.e. not equal to) the lastModified variable. Another option would to be to create subclass FileChangedOrRolledBackReloadingStrategy that overrides the hasChanged() method.

In either option the actual change is to use != instead of > in the hasChanged method's comparison:

return file.lastModified() > lastModified;