Elements: Consistent Defaults

[ax3l]

In our current workflow, we have to repeat ourselves quite a bit when it comes to defaults of element parameters:

• C++ constructor: purely informational, not used anywhere unless someone uses ImpactX as C++ library and does not pass explicit values (internally, we do pass explicit values in init)
• InitElements: the ParmParse/inputs defaults
• elements.cpp: the Python defaults
• parameters.rst: the ParmParse/inputs docs
• python.rst: the Python docs

This PR simplifies this for the first three to a single, authoritative source: the C++ implementation of the element.

PR #699 will then also unify the python.rst file into the same authorative source, leaving only the parameters.rst to be manually (or LLM-y) kept right.

Result, less repetition: 5x same value -> 2x same value

DRY programming like this is desirable where possible (not a hard rule*), since repetition leads quickly inconsistencies over time (e.g., #1445).
(*Programming everything DRY can also lead to hard-to-extend, rigid code, so we strike a balance.)

Changed Defaults

Same as #1445, the ExactCFbend, ExactMultipole, ExactQuad now use 10 mapsteps as the default.

Old C++ default was 10, too (init elements). But:

• C++ docs were off to 5.
• Python & its docs where off to 5.

[codspeed-hq]

Merging this PR will not alter performance

✅ 37 untouched benchmarks

---

_{Comparing ax3l:topic-elements-consistent-default (2cb9092) with development (ac4fe71)}

[cemitch99]

I'm taking my time a bit with this one. I have a slight concern that this increases the complexity of the element code by introducing a large number of DEFAULT_ parameters, most of which are zero. Otherwise, I agree it is a good way to ensure consistency.

[ax3l]

Yeah, I found the consistency to be worth the slight verbosity. Let me know where you arrive at @cemitch99