Drop march from platforms.yml if there is no use

[axel-h]

This is a follow-up from #283 (comment) to check if march has a deeper usage. If not, it could be removed to avoid confusion. Or replaced by something more clear as a selector. Seems the current fields that exist have a certain overlapping already from the history. Having the sel4arch as unification might be a way to go?

[lsf37]

The main current use is as a selector in the hardware build matrix so that we can have multiple jobs for e.g. Arm (armv7a, armv8a, previously also armv6). They're not the same as Arm 32 bit and Arm 64 bit, although that could be another set of dimensions to use for slicing the build matrix.

E.g. we could drop march and split by (arch, mode, compiler). This would leave arm, 32, x as the two largest jobs, probably longer than the current armv8a jobs. So maybe one more dimension that would cut arm, 32, x roughly in half.

[lsf37]

Maybe MCS, i.e. (arch, MCS on/off, mode, compiler). That should be roughly half the run time of the previous jobs.

[axel-h]

If the worry is the time, we could also group per platform. I tried this by having the python script generate the matrix from platforms.yml for builds also.
Showing the results more nicely seems a separate thing anyway, see #130

[lsf37]

You're right, we should probably at least try that.

[lsf37]

Coming back to this, when the workflow refactoring is completed, it should be feasible to play with this a bit more in the future.

Running each platform as a separate compile job could still be possible, but it would mean that even 2 PRs are already hitting the max number of GitHub runners, because there are a lot of platforms. It also increases overall overhead, because the setup and docker image pull etc is done many more times than before.

Overall I still think batching the build makes sense, just in smaller batches than before.