Feature/cljs devtools support

[stumitchell]

This PR adds a custom tracer that works well with cljs-devtools. As you see I have a couple of commits where I tried to refactor default-tracer but it ended out as worse code.

[noprompt]

I'm not thrilled with the duplication here but I see this could be of use to someone. This needs a little more thought before I'd feel comfortable merging something like this.

A quick scan seems to reveal the primary difference between the default-tracer and clj-dev-tools-tracer is pr-val but I may have missed something. Maybe a better way to handle the situation would be to

1. verify the dev-tools are available and
2. provide a way of enabling/disabling the dev-tools style printing.

If we can do both of these I see no reason why the default-tracer couldn't be enhanced to support this without the additional implementation.

[mike-thompson-day8]

@noprompt Your point 1 could be handled via a simple parameter to the tracer. Then there's no need to verify existence of clj-devtools (sounds like hard work for not much advantage). The programmer can turn this feature on or off, via the parameter to the tracer.

Which just leaves point 2 -- which would be based off the proposed parameter.

[stumitchell]

This commit day8@a6f4f28
shows how I attempted to avoid code duplication

for cljs-devtools we have to

1. change pr-val
2. disable fn detection and shortening
3. change the log-binding function to use different formatting
4. change log-exit and ITraceError not to additionally output to the console
5. change some of the (.groupCollapsed js/console ...) to (.log js/console ...) and remove the (.groupEnd js/console)

I produced a version that does both but the code wasn't really better for it I think.

I can definitely revert to that if you like, however, detecting cljs-devtools may be a bit too magical and explicit calling is probably better.

[noprompt]

As far as I know, the clj-devtools are still experimental and Chromium is still a requirement to even use the features it exposes. This already makes me hesitant to consider this patch. It's also why this library is protocol based.

Your point 1 could be handled via a simple parameter to the tracer.

@mike-thompson-day8 Parameterization seems like a good place to start but what other parameters might be needed in the future?