ASoC: sof: ipc4-topology: Add support to sched_domain attribute

[jsarha]

Add SOF_TKN_COMP_SCHED_DOMAIN and connect it to struct snd_sof_widget comp_domain member, with new get_token_comp_domain() function.

The logic is such that if the topology attribute is not present in the widget node the corresponding IPC4 extension value is taken from the module's manifest like before. But if the attribute is found its value overrides what is there in the manifest.

I do not yet know how to test this feature end to end, so that is why this is only Draft now. However, with a corresponding topology change the attribute is correctly passed to domain extension bit in widget setup message

[jsarha]

@ujfalusi could you approve this to get this merged?

[jsarha]

@lyakh , @ujfalusi , I still think no warning should be needed if we somehow encounter unrecognized topology value. Something like that should not really happen as long as the current topology attribute definition is not tampered: https://github.com/thesofproject/sof/blob/d6786df73a3e6185d06b90c2c02a3c54c63e7907/tools/topology/topology2/include/components/widget-common.conf#L124

But would it get this PR moving if I device a mechanism to provide a warning in such a case by introducing one more enum value for invalid string to be stored in swidget->comp_domain and report a warning in sof_ipc4_widget_setup_msg() about that value? That solution is far from ideal, as the warning would come only if that widget is set up, and always when its set up, but it could not tell what the wrong string was.

Of course the ultimate solution would be changing the prototype for struct sof_topology_token -> get_token() and add sof_dev there, but that is a big change touching all over the place, and I really don't thing it is in the scope of this PR.

[lgirdwood]

Just some simplifications.

[jsarha]

@ujfalusi & @lgirdwood , New version pushded. Hope its finally good.

[ranj063]

SOFCI TEST

[lgirdwood]

@ranj063 good to merge ?