[S] Change in coreboot[main]: genbuild_h: Fix and harden major/minor version parsing

[Nico Huber (Code Review)]

Attention is currently required from: Martin L Roth, Maximilian Brune.

Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/81290?usp=email )

Change subject: genbuild_h: Fix and harden major/minor version parsing
......................................................................

Patch Set 1:

(2 comments)

File util/genbuild_h/genbuild_h.sh:

https://review.coreboot.org/c/coreboot/+/81290/comment/40b3b410_9f8aa219 :
PS1, Line 39: MAJOR_VER="$(echo "${VERSION}" | sed -n 's/^0*([0-9]*).0*([0-9]*).*/\1/p')"
            : 	MINOR_VER="$(echo "${VERSION}" | sed -n 's/^0*([0-9]*).0*([0-9]*).*/\2/p')"
> The `-E` is posix compliant extended regex. […]

I'm not concerned about the regex itself, it's always possible to make it
posix compatible (by not using special operations). But I looked a little
into sed now. If sed should support the `-E', seems in flux. The Open Group
doesn't mention it [1]. Yet the GNU sed history claims since 2013 it would
be standardized. I'm pretty much puzzled.

So far we avoided it. And I really wouldn't want to risk anything as part
of a bug fix. If you want, you could add that in a separate patch, WDYT?

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
    That's 2017, and 2016, 2013 don't show it either.

https://review.coreboot.org/c/coreboot/+/81290/comment/5a5dce51_31beb784 :
PS1, Line 40: *
> 's/^([0-9]{2})\.0*([0-9]+).*/\2/p'

Without `-E` we don't have `+` nor `{}`. Also, the `{2}` would feel
like documenting when we started to use the new version scheme (after
2009) and would make other (downstream) versioning harder without
gaining us anything. I could change it to
```
's/^([0-9][0-9]*).0*([0-9][0-9]*).*/\2/p'
```
To make it clear to the human reader that we always expect at least
one digit. But It wouldn't change the result of the script (an empty
string is an empty string).
> Regarding other version formats as described in the commit:
> The substitution that you have currently in place also does not work for the version tag described in the commit-msg ("v1.9308_26_0.0.22"),

I know. I just wanted to give an example that people actually have different
formats and care about support for that upstream. At least so far that the
build succeeds. And we accepted that upstream. Saying let downstream handle
their special cases, would be changing that direction.