This is a followup of issue 122639 (and 162144).

While the new implementation uses index to speed up the Go to File action, there are still inefficiencies that could
slow down the action for large projects. Here are the steps to reproduce:
1. Create a new Java web application.
2. Create a class p.NewClass in this application
3. Select Navigate -> Go to File and type "N"

In the first part of the algorithm, the index correctly retrieves the NewClass.java file, which matches the search
criteria. However, in the second part of the algorithm, folders are collected so files are found outside of the source
roots. After this phase (as I verified under debugger), allFolders.toString has the following value:

"[/Users/petrjiricka/NetBeansProjects/WebApplication29, /Users/petrjiricka/NetBeansProjects/WebApplication29/nbproject,
/Users/petrjiricka/NetBeansProjects/WebApplication29/nbproject/private,
/Users/petrjiricka/NetBeansProjects/WebApplication29/src, /Users/petrjiricka/NetBeansProjects/WebApplication29/src/conf,
/Users/petrjiricka/NetBeansProjects/WebApplication29/src/java,
/Users/petrjiricka/NetBeansProjects/WebApplication29/src/java/p]"

In the third phase, on all these folders, folder.getData(false) is called, so the algorithm enumerates all the files in
folder /Users/petrjiricka/NetBeansProjects/WebApplication29/src/java/p, although these have already been retrieved in
the first phase through the index! 

I expect that all folders which are covered by the index, will not be collected in the second part of the algorithm, and
their children will not be enumerated in the third part.