Log TaskParameterEvent for scalar parameters

[ladipro]

Fixes #9827

Context

TaskParameterEvent with TaskParameterMessageKind.TaskInput is currently used only for parameters that are lists. Parameters that are simple strings are logged as a specially formatted low-importance message.

The binlog viewer contains logic to recognize this special message and recover the Name and Value to be rendered in the viewer UI. Since we will use this event for analyzers, it would be unfortunate to add one more place with this suboptimal processing.

Changes Made

Unified the logic in TaskExecutionHost to log all parameters as TaskParameterEvent with TaskParameterMessageKind.TaskInput. The change is under a change wave check.

Testing

• Added a new unit test.
• Compared diagnostic-level output with task parameter logging enabled with and without the change. No differences were found when passing null, empty, false, true, numeric, string, or stringified item list parameters.
• Compared the appearance in binlog for the same sample values as above. No differences were observed.
• Compared OrchardCore binlogs with and without the change. They're the same size and the only difference I found was in rendering the SolutionConfigurationContents parameter which is a string but the content looks formatted so it was rendered incorrectly as a list of items.

Notes

As @KirillOsenkov pointed out in the issue, we don't really depend on the textual messages so we don't have to do any double-logging. The viewer can remove parsing the textual messages on its own schedule.

[KirillOsenkov]

Let's check that the diag output for console loggers doesn't change, as well as let's see how it looks like in the binlog for null, empty string, numbers, booleans and such.

What is the current behavior for scalar parameters that have the default value? (0, null, false)

[JanKrivanek]

Looks good.

+1 on quick manual test of binlog and FileLog appearance for the change

[ladipro]

Done. No differences found with our textual logging (with task parameter logging enabled) or with the way it looks in the viewer. I have exported the tree as XML from the viewer and the SolutionConfigurationContents mismatch is still the only difference I've found.

[ladipro]

I am adding screenshots of SolutionConfigurationContents for completeness.

Before:

After:

Before looks nicer but it's lying.

[AR-May]

LGTM

[KirillOsenkov]

Just a note that the viewer can't remove parsing textual messages because we still need to read all legacy binlogs.