Haxe should never use the root directory on Unix machines as a potential classpath.

This is a fix to a <em>very frustrating bug</em> in the (otherwise wonderful) Haxe compiler, which may affect Mac users who write macros. The bug has been there since 2006, but it's very rare. In fact, it has probably only affected me. So I'm taking its eradication very personally.

Did you know that many DNS servers will attempt to auto-correct the queries they receive? Did you know that many public wifi routers will redirect all DNS requests to their sign-in page?

And did you know that on Unix machines, there is a filesystem called 'autofs', which makes DNS queries whenever processes attempt to access files at certain locations?

Did you know that autofs will often do this when a filepath matches '/net/*', as specified in /etc/auto_master on said machines?

Also, did you know that the NekoVM embedded in the Haxe compiler will search for top-level classes, such as String.hx, at paths like '/net/String.hx' when running a macro from within a class whose package matches 'net.*'?

In other words, did you know that <em>any</em> Haxe project that runs macros from within a package matching 'net.*' on a Mac will stall until autofs responds to each request for a top-level class? (Which is to say, when the local DNS responds to autofs? (Which is to say, when <strong>THE INTERNET</strong> responds?))

Useful information, right? I've acted on this information by removing '/' from the Unix classpaths in main.ml. But what I'm still left wondering is, <em>why were we searching for Haxe classes in '/' on Unix machines in the first place?!</em>

Hopefully, garnishing San Francisco's DNS logs with the filenames of Haxe classes has helped promote my favorite programming language to such lofty institutions as the Bay Area Rapid Transit District, Peet's Coffee and the NSA.

[Here's a Gist demonstrating the issue.](https://gist.github.com/Rezmason/8249090)