Fix emacs highlighting of symbols that contain keywords.

Previously, symbols such as `prepend!` or `net_required_for` incorrectly
had `end` and `for` highlighted.
`in` is a keyword, so highlight it.
Highlight types in all type annotations.
Highlight parent types in type declarations.
Highlight parameter types and subtypes.
Don't highlight that that happens to contain a constant.

For example, `Inf` in `StaticVarInfo`.
use winepath and spawn with stringreplace

for cross compiling - wine apparently auto-mounts and translates /home,
but if you build julia somewhere else then mingw-compiled stringreplace
can't understand unix paths (same issue as on cygwin)
Remove some redundant dates tests to make dates test suite run a little faster.
Fix remaining 32-bit test failure by making sure Periods are parsed as Int64, regardless of WORD_SIZE
Dates manual chapter cleanup/update
Remove subtype of AbstractTime for Slot.
Cleanup some Dates module qualifiers
Put Dates tests in their own module to prevent method binding overwriting
Merge branch 'master' of https://github.com/JuliaLang/julia
doc/stdlib/dates: Update current module scope
doc/stdlib/dates: Fix formatting of functions and table
Fix #6757

this issue is quite subtle and originally I had assumes it was a bug in LLVM,
because it heavily depends on which optimizations are enabled, but it turns
out that it's actually a missing annotation in our IR. Before I describe what
the underlying issue is, there is a similar description in the commit
by @isanbard when this was originally found (in Clang, I presume) at [1].

The dlm_fill function has an interesting pattern, where, when it can't parse
the given data with the requested type, it will try again by calling itself
with a more generictype. This and the call to store_cell however, go through dynamic
dispatch, so the dims tuple that is passed in unboxed, needs to be reboxed for
dynamic  dispatch. The problem seen in the original issue stemmed from the fact that
the dims tuple, which was originally passed in as (2,2), suddenly became (1,2)
for the second call. This happened by the following mechanism:

dims=(2,2) gets passed in via XMM0 and gets almost immidiately spilled to the stack.
Sometime before the generic call to store_cell (and potentially eariler functions),
dims is reloaded from the stack slot in order to extract the components and box
them individually for the generic call. At this point LLVM thinks that there is
no use for the original stack slot in which dims was stored anymore and proceeds
to reuse it (the optimization pass responsible for this is StackSlotColoring).
We now get to store_cell, which throws an exception that longjmps us back to
almost the beginning of dlm_fill where dims was still in the stack slot. However,
said stack slot has been overwritten, thus causing the corrupted dims tuple
in the second go-around.

The solution to this on the llvm side is shown in [1] below, i.e. simply disabling
the StackSlotColoring pass. However, this check did not fire on our IR, because
we weren't marking the call site as return twice. For better or for worse, LLVM
requires most attributes to be duplicated on the call site as well as the callee
(where we had already set this attribute).

[1] https://github.com/llvm-mirror/llvm/commit/5edfbdc9635405fe601d6d4645443d3a38c5e7b7
illegal -> invalid in the manual
updated julia-mode.el for recent latex-symbol additions (#7961 and #7962)
NEWS updates