Consider removing stacktrace support

[sparkofreason]

hashtag currently provides a mechanism to process and return the stacktrace.
However, unlike local bindings, stacktrace is available at runtime
(vs. compile-time), and so can be grabbed by a custom handler function.
Benefits:

• Removes the only dependency (clj-tacktrace) from hashtag
• Allows handler authors to process stacktraces as required, based
  on the environment, other tooling, whatever, rather than forcing
  default choices (e.g. dropping the first 3 frames by default.)
• Simplifies extension of hashtag to ClojureScript (ClojureScript support #1).

[green-coder]

To keep in mind: Power users who will override the stack logging are a minority. For most of the users, it is convenient to have a default behavior that works out of the box.

[sparkofreason]

I'm considering a different approach, maybe some utility functions in a different ns to make it easy to work with the stack trace as opposed to the hard-coded options. The current implementation is probably too limiting, because anything that modifies the depth of the call stack relative to the desired "top" frame (I'm thinking instrumentation of functions) will break it.

[sparkofreason]

AFAIK, there is no unified stacktrace -> data mechanism that applies to both Clojure and ClojureScript. I've updated hashtag to include the current namespace and the line/col (via metadata from the form), which at least covers the common use-case of seeing where the hashtag was placed that yielded that associated debug data. Removed :stacktrace-tx and added :stacktrace?, which just adds the raw-ish stacktrace for the environment (CLJ/CLJS), with some very minimal processing to remove the hashtag-related stackframes.