record printed forms that are consistent with Clojure
Merge branch 'master' of github.com:clojure/clojurescript
CLJS-351 : replace .-length usage with alength
Added a default case for the emit-constant multimethod.

The emit-constant multimethod got dispatch values that it was not prepared for, such as java.lang.Class, for some code.
Even the regular :require clauses are now attempted in order to fetch macros. This is to avoid having a breaking change in ClojureScript.
We at least want to be able to get a chance to test ClojureScript code out on the 'real' Clojure.
Added a flag to the compiler function(s) deciding whether to compile .clj files as well.

The logic right now is as follows:

Both .cljs and clj files are tried, both read into the JVM and to be compiled
to JavaScript. BUT, if a file ends in .clj it has to have a speical
marker form somewhere in the source in order to result in a JS file,
and you will get a warning message if it removed the generated JS file.

The special marker is

    (comment *target* clojurescript)

So, now you can use regular :require clauses in your ns declaration,
and also use .clj as suffix for all files in the project, no matter
whether it is on server side, client side or macros for client side
purpose.
Now even the files that were successfully required into Clojure will be tempted for JS generation.

NOTE: those .clj files must have a special ClojureScript marker
in them though, to actually in the end generate JS files.
The compiler feature/directive system now works.

One can specify directives in the form of

   (comment **compiler** :feature value)

Compiler features are also heuristically assessed by the system.
Heuristics is a big word for checking that the filename extension
is ".cljs"...

With this system in place, one can now safely use .clj for
ClojureScript files and place macros in source files used by both
the macro system (in JVM) and the target JavaScript code, it is
just so that the macros will be ignored in runtime.
Added an 'ignored' set which is similar to the 'specials' set except that the matching forms are just ignored.

The main reason was to add 'defmacro' as a form type that should just be discared when generating JavaScript. It now does so, so we can finally allow for macros to coexist - albeit in a slightly different dimensional hyperplane - with the 'regular' code.
Refactored the resolve-var functions, and combined them into one.

There were previously various versions of the same undocumented spaghetti if-else code. This is not acceptable, so I will refactor it all. Started with the two almost identical resolve-var and resolve-existing-var functions. Will incorporate get-expander as well into this simpler homogeneous solution. What happened to code quality? Ugh. Strange, like people think 'write once' actually means that nobody will ever need to understand the code again, including themselves a few weeks later.
Added two contrib modules to the bootstrap
Refactored the symbol resolution to use only one, resolve-var, instead of the previous there.
Using versions of var resolution that are very close to the original, yet allowing for macros to be loaded from any file, and skipping the silly require-macros
Introduced a :stub compiler feature which tells the compiler to stop processing and just output what it has
Disabling our own var resolution for now
Added a compiler feature :macros which allows the developer to mark certain namespaces as macro-only without using the breaking uses-macros facility