This allows any compiled instrument to run with --trace=0

[willend]

In 3.5.27 and earlier recent releases, running e.g.

1. mcstas my.instr (leaving out --trace)
2. mcrun my.instr (for compilation)

results in this type of error message, since mcrun passes --trace=0 to the resulting binary:

mcrun PSI_DMC.instr 
INFO: No output directory specified (--dir)
INFO: Using directory: "PSI_DMC_20250511_195047"
INFO: Using existing c-file: ./PSI_DMC.c
INFO: Recompiling: ./PSI_DMC.out
ld: warning: duplicate -rpath '/Applications/McStas-3.5.27.app/Contents/Resources/miniconda3/lib' ignored
INFO: ===
Error: trace not enabled (mcenabletrace)
Please re-run the mcstas compiler with the --trace option, or rerun the
C compiler with the MC_TRACE_ENABLED macro defined.

This PR allows any compiled instrument to run with --trace=0 irrespective of compiled-in support.

To actually use visualisation mode, --trace needs to be assigned a value (1/2), since introduction of the modernised mc/mxdisplay with --trace=2 or legacy --trace=1.

The instruments now only report an error if --trace are built without MCDISPLAY support and actually given a non-zero value.

[willend]

@farhi @g5t @mads-bertelsen @tweber-ill I was also considering to swap the default, i.e. let all instrument have MCDISPLAY enabled and instead add a --no-trace option for those who insist to not compile support in?

Anyone running using mcrun, mcdisplay or McStasscript will in practice have this behaviour already, since these tools all are mcrun in disguise - which means mcstas --trace. I recently tested, typical instruments compiled without mcstas --trace run maximally 5% faster.

Also, in my view the users are most often confused that the default of the mcstas cogen is in some sense different than that of mcrun... :-)

What do you think? (I will actually copy this across to a "discussion" - better place to have it I think...)

[farhi]

That makes sense indeed. 5% faster means a coffee during calculation. I vote for.