ux: move translator load msg into translator instantiation

[leondz]

Don't show translation loading message when not doing translation
Show message during translation service load, per instance (consistent with other CLI output behaviour)

Verification

• garak -m test -p test.Test - no globe on CLI
• garak -m test -p test.Test --config riva_translation.yaml - globe on CLI (for some valid Riva conf doing MT)

[jmartin-tech]

This is not an appropriate action for a service object instance to take. Also as implemented this would output twice with as the message would be printed for each translation pair required [en-fr, fr-en] for example.

There is already a a logged entry as each translator is created written by langservice.

As it stands harness is the first required entry adding logic in _initialize_runtime_services()to suppress the message if translation will not occur is a more acceptable pattern.

[leondz]

This is not an appropriate action for a service object instance to take.

To address this opinion the code should be consistent, and the CLI UX should remain unaffected, which means coding separation of logic & presentation for CLI. That coding doesn't deliver enough value so I suggest following existing design & practice

Also as implemented this would output twice with as the message would be printed for each translation pair required [en-fr, fr-en] for example.

This is the desired behaviour. We give CLI users information about what they're loading. Alternatives considered but not adopted include:

a. printing an abstract, general message (uninformative - it doesn't describe what is happening in enough granularity)
b. printing only the first message (misleading if there's a crash during the reverse model load)

As it stands harness is the first required entry adding logic in _initialize_runtime_services() to suppress the message if translation will not occur is a more acceptable pattern.

I'm not sure that Harnesses should orchestrate these loads. It feels like scope drift. With the command/cli refactor postponed until we have a solid pattern for calling garak within Python from outside garak (i.e. after another service lands as discussed), I can live with it being here instead of that future orchestration within a command method. Wdyt?

[leondz]

updated pending validation

[jmartin-tech]

This pattern works for me, a looks like a few unneeded changes and some renamed values need to be accounted for.

[jmartin-tech]

This message printed currently relies on information that is not required in the configuration file.

[jmartin-tech]

Awesome, looks good!