Use an OptimisticFileModificationService by default within BRJS, but
provide a setFileModificationService() method that allows the service to
be changed later -- this is necesarry so that commands that need file
watching can enable it later.
Stopped injecting the FileModificationService as a dependency into BRJS,
and instead assumed the OptimisticFileModificationService by default,
but where BRJS.setFileModificationService() can be invoked if this is
not suitable. As a consequence of us know using the
OptimisticFileModificationService for both test and non-test
environments, created a new TimeAccessor dependency that must be
injected into BRJS, and will be different in test and not-test
environments.

The BRJS.setFileModificationService() is complicated by the fact that
many FileInfo objects will already have been issued by the time
etFileModificationService() is invoked, and since these FileInfo objects
wrap a FileModificationInfo object that will have been created by the
previous FileModificationService, we need a way to dynamically swap the
implementations around. This is done using the BRJSFileInfo class, which
proxies through to an underlying FileInfo object that can be swapped out
as necesarry.
Improved the feedback we get when assertLibsListsAreSame() fails.
Removed an unnecessary semi-colon.
Got rid of BRJS as a dependency for FileModificationService to make it
easier to test.
Merge branch 'develop' into
windows-file-watching-performance-improvement

Conflicts:
	brjs-core/src/test-integration/java/org/bladerunnerjs/spec/Java7FileModificationServiceTest.java
	brjs-core/src/test/java/org/bladerunnerjs/utility/RelativePathUtilityTest.java
	brjs-core/src/test/java/org/bladerunnerjs/utility/filemodification/PessimisticFileModificationInfoTest.java
Updated the ThreadSafeStaticBRJSAccessor so that it no longer switches
to a Java7FileModificationService (allowing the performance benefits to
be gained), and updated the RestApiServlet so that it no longer switches
to a PessimisticFileModificationService to prevent caching bugs, which
was for some reason was completely killing performance once I'd made the
first change.

Both of the above changes will provide better performance, but I've also
had to make some changes to avoid the potential caching bugs you can get
from updating the model via the API then expecting queries to
immediately reflect those changes:

  1. FileInfo.resetLastModified() now invaliadates all parent FileInfo
objects too.
  2. Updated the FileModificationServiceNodeReadyObserver to invoke
resetLastModified() on nodes that have been added.
  3. Updated the RestApiService to manually invoke `resetLastModified()`
after updating any existing nodes.
  4. Properly implemented some of the NonExistentFileInfo methods to
avoid the situation where resetLastModifed for a known file is thrown
away because the watcher hasn't yet become aware of the file the first
time around.
  5. Updated OptimisticFileModificationService to provide different
FileInfo objects for each file now that the resetLastModified() methods
actually work.
Only replace the file modification service if ServeCommand.doCommand() is invoked, so that  isn't slowed down too.
fixing some NPE when symlinks are in any part of the model
fixing NPE when importing an app
Removed invocation of BRJS.setFileModificationService() from directly
within a test and used TestModelAccessor to do this instead.
Deleted the FileModificationServiceNodeReadyObserver as it was slowing
down the `build-app` command, yet removing doesn't seem to have led to
any bugs.
Stopped invoking resetLastModified() in the constructor as this now
causes the timestamp of all ancestor objects to be reset too.
Merge pull request #989 from BladeRunnerJS/windows-file-watching-performance-improvement

Windows file watching performance improvement