sys/mod doc update and mod import order adjust

[king6cong]

• Some doc updates.
• Racer currently use the first mod it finds regardless of cfg attrs. Moving #[cfg(unix)] up should be a temporary tweak that works as expected for more people.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

@bors: r+ rollup

[bors]

📌 Commit b821313 has been approved by alexcrichton

[lilianmoraru]

@king6cong@alexcrichton
Using #[cfg(target_os = "redox")] seems problematic to me.
You can have the host unix/windows and the target redox - shouldn't there be conflicts?
If this works for reasons I don't understand, than think of the build.rs "script".
A crate like tempdir(it's not the best example in the case of tmp, think setenv function), how does it decide which implementation of temp_dir() to use. It has to work in build.rs and also in an application that runs in redox.

Edit: In the case of build.rs I think I confused things. It will be built 2 times, for host(for build.rs) and then again for the binary/library.

Edit2: Now seems to me that the other 2 are incorrect.
Shouldn't it be target_os for all? What if you cross-compile?
Did anyone try to cross-compile to unix targets from Windows?
It seems to me you should not be able to cross-compile from Windows to emscripten as an example.

[alexcrichton]

@lilianmoraru oh it may make sense if I say that unix/windows/redox are all mutually exclusive, so only one of these modules ever exists.

[lilianmoraru]

I confused cfg ([os]) meaning cfg(host_os) instead of cfg (target_family)