Remove MrAnderson dependency inlining

[bbatsov]

I've been frustrated with MrAnderson for a while now, and I think the time has come to just drop it.

It served us well over the years, but it adds a lot of complexity for diminishing returns — a SNAPSHOT plugin dependency, dual CI test matrices, runtime workarounds (dynamic keyword/symbol construction to sidestep namespace rewriting), build hacks (manually deleting files post-inlining), and conditional env vars for tooling compatibility. The three remaining inlined deps (cljfmt, tools.namespace, tools.reader) are all stable Clojure libraries with strong backwards compatibility, and we already un-inlined orchard, compliment, clj-reload, and suitable without issues.

This PR makes cljfmt, tools.namespace, and tools.reader regular dependencies and removes all the MrAnderson machinery — plugin config, target/srcdeps build step, full-test CI job, CIDER_NO_MRANDERSON env var, runtime keyword construction workarounds, and the associated docs.

[alexander-yakushev]

To be honest, I feel a bit uneasy about moving tools.namespace and tools.reader out of Anderson. They are so commonly encountered as dependencies, and the version range is so huge, that something somewhere will surely break because of this.

Have you considered manually vendoring these deps?

Also, I had a dream of replacing tools.namespace with clj-reload at some point, but making possible to provide an explicit tools.namespace dependency if the user needs it.

[bbatsov]

To be honest, I feel a bit uneasy about moving tools.namespace and tools.reader out of Anderson. They are so commonly encountered as dependencies, and the version range is so huge, that something somewhere will surely break because of this.

I've manually checked the commit history for both of them for the past 5 years and I don't see that much activity there, plus cider-nrepl is relatively light user of both (especially tools.reader), so it seems to me it's probably less dangerous than it might look. One of the nice aspects of contrib projects is that they barely move these days. I think as long as the user projects have version 1+ (and probably most do) - we should be safe.

Have you considered manually vendoring these deps?

It crossed my mind many times in the past, but now I'm trying to do the simplest thing possible, that's why I'd rather avoid this unless it's actually necessary.

Also, I had a dream of replacing tools.namespace with clj-reload at some point, but making possible to provide an explicit tools.namespace dependency if the user needs it.

I've thought about this as well, although if we imagine that tools.reader is the bigger problem - it's used for the EDN format functionality and it's also a transitive dep of cljfmt.

Anyways, I'm not pushing for this right away. I did this PR mostly as a POC/conversation starter.