Simplify and speedup compilation database generation

[Repiteo]

Gives the compilation database code some TLC, as the previous implementation caused a lot of --debug=explain output bloat. While I think this will always be an expensive action to some extent, here's an anecdotal comparison of the difference I saw from an MSVC build of the Godot Engine that's already been built:

Method	Node Count	Build Time
Disabled	17,161	00:16.61
Enabled (Old)	20,008 (+2,847)	00:19.54 (+2.93)
Enabled (New)	17,163 (+2)	00:18.38 (+1.77)

The one area I couldn't figure out was making the entries function as a dependency for the compilation database itself, so it's still set to always build.

Contributor Checklist:

• I have created a new test or updated the unit tests to cover the new/changed functionality.
• I have updated CHANGES.txt and RELEASE.txt (and read the README.rst).
• I have updated the appropriate documentation

[bdbaddog]

Can you give a high level summary of your changes? (But lower than made it faster.. ;)

[Repiteo]

The most obvious change is the removal of __CompilationDbNode, as that ended up being an unnecessary middleman. I think the original intent was to have those somehow function as dependencies for the compilation database at MongoDB, but they were set to always build since their introduction in this repo, so they were doing extra work for no real benefit. I'm not certain how much faster that specific change ended up being, but it was the reason that the overall amount of nodes decreased by nearly 3k in my test scenario

A secondary boost was from only having to create the commandstr actions once-per-variable. The old implementation was effectively doing a lambda call each time it was validating a commandstr, instead of falling back on a cached function.

Tertiary changes include making the output file always use Unix eol and UTF-8 encoding, as well as using more modern syntax to make some sections less verbose. Also removed the scanner because it did nothing. It quite literally did nothing. It might've at one point in MongoDB, but it was totally vestigial

[bdbaddog]

I'm a bit slammed at the moment and this will take a deeper dive to review, so please be patient for feedback..

[bdbaddog]

What happens if your build system has more than one Environment()? Seems like with the global gone, it would only output the information for items built with the current Environment()?

[Repiteo]

Hmm, that's tricky. On one hand, it'd be convenient to allow multiple compiledb outputs based on the environment that called it. On the other hand, that's very much NOT how the current implementation handles it, and I don't want this PR changing observed functionality

I'll go ahead and bring back the global for this PR