Get rid of externs requirement for pure CLJS builds

Start in datascript.query at the getter-fn and inspect the aget uses for property-name inconsistencies, then review the JS build-related code and README.md guidance about externs. Compare pure CLJS and JavaScript-targeted builds; done means the pure CLJS build no longer requires externs while the existing JS build continues functioning.

There is a very long open issue that datascript requires externs even for pure CLJS compilation. This should never be neccessary for builds where all code is part of the build. Given that shadow-cljs doesn't add externs by default this creates problems. It even has become part of the entry README.md since I assume this is a common issue.

I had a suspicion what the problem is and used AI to confirm. It did, but I do not know enough about this codebase to know if its suggested fixes would actually work. So, here goes the problem.

The code is running into the Inconsistent Property Names problem. Meaning that some places use foo.e and other use foo["e"]. Or more likely the CLJS variants of (.-e foo) and (aget e "foo") (or unchecked-get or any other string based property access). I can see several uses of aget in the codebase, most notably the getter-fn in datascript.query. Given that the set of property names is known it can just use direct getters and not mix in string lookups.

There is also another situation where code contains forced goog/exportSymbol code that is also never necessary for pure CLJS builds and should only be present for the JS targetted builds, not part of the raw sources the CLJS builds will use. But that is a different unrelated issue. Just leads to a lingering datascript global that is also causing problems in ESM builds.

I'd advise moving all the JS build related bits into their own files and doing that build with externs. That would leave the JS build functioning as is, while likely fixing all the CLJS related build issues.

I have no interest in pursuing this myself any further, but given that AI can most definitely fix this, I thought I would bring it up just in case there is any interest in "fixing" the current situation.