Enable Glagol support by translating slashes in identifiers to dots

[egasimus]

This is a patch which allows for compatibility with Glagol, a clever little live coding framework that I've been working on for the last few months. One of its main features actually originated from this very hack; turns out that replacing slashes with dots allows (./foo/bar baz) to be translated to _.foo.bar(baz) rather than the nonsensical _.foo/bar(baz). This is not only more consistent with how namespaces are currently handled in Wisp, but, in Glagol, allows you to use a path-like syntax to get the values of neighboring files (which are helpfully provided by Glagol in a _ global object.)

I understand that this is a somewhat weird feature and not consistent with the Clojure side of things (AFAIK Clojure does not support anything like nested namespaces). Still, I consider it beneficial to contribute this to upstream, so that Glagol can support Wisp out-of-the-box without having to maintain a patched fork. (I actually tried monkeypatching the writer at runtime -- but, within the writer module, the original var reference to the unpatched function was preserved, so it didn't work).

I have also fixed an assumed typo in the docstring for translate-identifier-word.

[vendethiel]

-1. I don't think your only incentive ("looks better for file loading in glagol") is enough to introduce such a big change.

[egasimus]

I fail to see how this is anywhere close to a big change: it's pretty much inconsequential outside of the stated use case, and does not make any less sense than the current behavior. On the other hand, I feel like I'm onto something with Glagol, and would like it to offer first-class support for Wisp. (To clarify, path literals are such a central feature because they always return the up-to-date result of evaluating that file, rather than just load its source text and call it a day.)

I am open to suggestions though. If there is a more semantic way to add relative path literals to the language, I could give it a go. But it seems that dispatching in reader.wisp is hardcoded and there is no function that corresponds to install-special!/install-macro! for cleanly extending it. Sure, refactoring the reader to accommodate custom reader macros would be good for more than this one thing, however there's a chance it would end up a considerably more complex endeavour than the currently proposed one-liner fix which doesn't break compatibility in any way I can think of.

[vendethiel]

It's a big change because, as you stated, it parts way with the cljs way (whIch uses / for namespacing)