direct: Migrate legacy DConfig usage to modern configuration interface

[darktohka]

Issue description

Some modules in direct are still using the old DConfig interface (config.GetBool and friends). They should be migrated to the new ConfigVariableBool (and friends) interface.

Solution description

This PR consists of three commits:

• a46dd2d: which replaces the value property accesses to the getValue() method call
• 7cb229d: which removes the old temp-hpr-fix setting, which is no longer used, from the contributed sceneeditor module
• ffd3839: which replaces the config.Get* calls with ConfigVariable* usages

Checklist

I have done my best to ensure that…

• …I have familiarized myself with the CONTRIBUTING.md file
• …this change follows the coding style and design patterns of the codebase
• …I own the intellectual property rights to this code
• …the intent of this change is clearly explained
• …existing uses of the Panda3D API are not broken
• …the changed code is adequately covered by the test suite, where possible.

[codecov]

Codecov Report

Merging #1333 (ffd3839) into master (2208cc8) will increase coverage by 0.09%.
The diff coverage is 30.58%.

@@            Coverage Diff             @@
##           master    #1333      +/-   ##
==========================================
+ Coverage   16.09%   16.18%   +0.09%     
==========================================
  Files        3739     3739              
  Lines      363643   363741      +98     
==========================================
+ Hits        58518    58883     +365     
+ Misses     305125   304858     -267     

Impacted Files	Coverage Δ
direct/src/cluster/ClusterClient.py	16.55% <0.00%> (ø)
direct/src/controls/GravityWalker.py	15.02% <0.00%> (ø)
direct/src/directtools/DirectSession.py	0.00% <0.00%> (ø)
direct/src/distributed/ClientRepositoryBase.py	17.22% <0.00%> (ø)
direct/src/distributed/ConnectionRepository.py	14.16% <0.00%> (-0.05%)	⬇️
direct/src/distributed/ServerRepository.py	9.92% <0.00%> (ø)
direct/src/interval/AnimControlInterval.py	15.11% <0.00%> (ø)
direct/src/leveleditor/ObjectMgrBase.py	0.00% <0.00%> (ø)
direct/src/particles/SpriteParticleRendererExt.py	19.27% <ø> (ø)
direct/src/showbase/DConfig.py	50.00% <0.00%> (ø)
... and 41 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2208cc8...ffd3839. Read the comment docs.

[rdb]

What's wrong with using the new Pythonic .value property as opposed to the getter method?

[darktohka]

It's used inconsistently. Some code in direct uses the value property, some code uses the getter method. I personally prefer the getter method, since it doesn't imply that the "value" property can be assigned. I wouldn't be against an inverse change either, however (changing all getter method accesses to the value property).

[rdb]

I see no advantage of using .getValue() over .value. The latter is faster, less visually cluttered, and naming convention agnostic. I reckon we will eventually deprecate the former in favour of the latter, so I would suggest the inverse change.

Not sure what you mean by "doesn't imply that it can be assigned". It doesn't imply such a thing (read-only properties are common), but it can be assigned, if you wanted to.

[Moguri]

Let's leave existing ConfigVariable* getValue(), setValue(), and value calls alone for this PR to reduce clutter (the style update can go in a new PR). For new code, I prefer using the property over the methods.