#898 IntelliJ FileSystem implementation needs to be reimplemented from scratch

[Stefan Rossbach]

After taking a closer look at the current API that IntelliJ provides, the current implementation is beyond broken, full of unnecessary custom self made stuff that is not needed at all.

Issues:

Accessing datastructures (e.g #members()) without requiring the read lock.

Self made maps of files to replaced already provided API functionality like: https://github.com/JetBrains/intellij-community/blob/master/platform/core-api/src/com/intellij/openapi/vfs/VirtualFile.java#L347 (see IProject#findMember()).

The requirement of IntelliJ project instances, although IntelliJ modules should be shared (which are already unique by their names, even among multiple projects).

Ignoring the fact the modules may contain submodules and therefore have to be filtered out for #members() and #findMember() invokations.

The lack of converting VirtualFiles to IFiles along with their corresponding modules.

Ignoring the fact the IntelliJ modules may have multiple content roots, etc. pp.

[tobous]

The new handling of the filesystem through the IntelliJ OpenAPI is implemented and integrated through the changes 3397 to 3430. This integration is not completed yet as the classes FileSystemChangedListener and SharedResourceManager still have to be adjusted.

[tobous]

When adjusting the FileSystemChangeListener, the handling of files created from a template needs to be reworked as well. See #889 and #863.

[tobous]

When adjusting the SharedResourceManager, the handling of remote file deletions needs to be reworked as well. See #897.