Project tree refactoring fixes

Fixed tons of errors and unsupported cases, mainly in the Move command. Should fix issues #144 #162 #187 #400 #518 and several more issues not reported.
Rename command left modified files unsaved, while Move command saved them, the latter is the common approach taken, and I'd say seeing tons of files with unsaved changes may confuse the user, so made Rename to behave the same.
The Move command tried to keep modified files open, but the code was wrong, I fixed the initial check but left it commented, I think it pollutes the user interfaces when the refactoring affects many files. If this feature is wanted it would require some further changes.
When the Move and Rename commands finish, the affected files that were initially open are kept open, although the position is lost.
Removed calls to RefactoringHelper.GetSearchPatternFromLang and use Project.DefaultSearchExtension instead, that way everything is centralized, this allowed to see the default search filter of Haxe projects was missing the recently added .hxp files (confirmed to be an oversight), and made finding references able to find matches in code sections of MXML files (no extensively tested).
Made folder-package check case-sensitive, as it's the right thing to do.
Well, in other parts the same is done but through a list, this is a more performant (although a insignificantly more memory consuming) way of checking if a path is already added. Either a Dictionary or a List, I see the resulting code to be equally readable. 

I admit that for a short collection choosing one type over the other is trivial, so if you prefer a List I could change it. At any rate, as I commented, once the code is integrated in the fd5 branch, that part of code will be completely replaced.

If there were no other way, in .NET 3.5 I'd use a HashSet instead of a List or Dictionary. Removing completely the collection could bring performance problems if an user has a path with tons of code files repeated.