Instead of wiping the old toolbar out on the server side we now just wrap the old toolbar in a div that has an inline style that prevents it from being displayed. This is only done when the toolbar is enabled. When the toolbar code runs on the client, if the toolbar ends up being incompatible, the old toolbar's wrapping div is shown. This avoids the side-effect of the old toolbar showing up momentarily while the new toolbar loads. It's a dirty hack, but we explored this extensively and it's the least evil way we could come up with that worked consistently.
Change-Id: I6fefadea4dbd01b96a0b95c50bc9ef526144dc3c
What actually happens here
* Add $localBasePath, $remoteBasePath params to the FileModule constructor, defaulting to $IP and $wgScriptPath respectively
* Add getLocalPath() and getRemotePath(), which use this information to build a proper FS or URL path for a file
* Make readScriptFiles() non-static so it can use these functions
* Run every single file path we use through either getLocalPath() or getRemotePath() as appropriate
** Except file dependencies, these are already prefixed. Our inability to give them special treatment caused bugs earlier
* Kill prefixFilePathList() and resolveFilePath(), no longer needed
