[wien2k] Add init_dmftpr, the case.indmftpr generator

[harrisonlabollita]

Summary

This PR ports the Wien2k-style initialization program `init_dmftpr`` from dft_tools to dftkit.

dmftproj takes a case.indmftpr file as input to generate projectors. Writing it
by hand means matching a positional format with one lsort/lnreps entry per l, so
this ports the interactive generator from triqs_dft_tools (bin/init_dmftpr):
it reads case.struct for the species and multiplicities, asks what to project
and how, and writes the file in the layout dmftproj expects.

Installed with install(PROGRAMS) so the execute bit is set, unlike the
install(FILES) dft_tools used.

Fixes carried over during the port

• The energy window is always written. Previously a third token that was not
  exactly ev/eV/Ev — e.g. -0.6 0.14 Ry, or EV — fell through the unit
  test without writing anything, silently producing a case.indmftpr with no
  window line at all.
• The struct file is taken as <case>.struct rather than the first *.struct
  glob match, which could pick up a stray struct file.
• Orbital letters are validated instead of raising KeyError.
• The file is written only once every answer is in, so aborting part way through
  cannot leave a half-finished case.indmftpr on disk.

[the-hampel]

Looks clean. Thanks @harrisonlabollita ! So I guess we should then eventuall retire the one in dft_tools? Otherwise these bite each other? Should we remove it there?

[harrisonlabollita]

Ah, that's a good point. I think we should. dft_tools depends on dft_kit now correct? Then the experience would be consistent?

[the-hampel]

Hm, in the end we do not enforce having dftkit for dft_tools. That was the case for a brief moment but we removed it because then modest and dft_tools would pull both dftkit in and that would clash. But I think we can anyway remove it on dft_tools. But only on unstable. So on the next release it will land but for 4.0.x we maybe keep it as is. What you think?