Make Errno enum values a set union of all possible LibC Errno values

[oprypin]

So, if an error name is available on at least one platform, it is possible to refer to it on all platforms, even if its value is INVALID = -1.
That is in accordance with Crystal's planned API guarantee: if it compiles on one platform, it should compile on any platform.
This is not problematic because all usages should be of the form if err == Errno::ENOATTR, and if such a value is not possible to encounter on a given platform, it's expected that the equality will never be true. Additionally, if the platform in the future gains more possible error codes that we're not aware of yet, the equality with them will also be false (they are not clumped into INVALID but rather have their normal integer value, just that it's not known to the enum -- to_s and such).

Also update and sort the list of all errors accordingly.

---

Prior discussion: #8885 (comment)
This is an alternative to #9523 (comment)

[aravindavk]

Looks good. Thanks for all the clarification.

This is an alternative to #9523 (comment)

Not an alternative. Because that PR is supposed to add the missing error numbers. I will rebase my PR to add new error codes to respective platform-specific files and to src/errno.cr file.

[oprypin]

This is an alternative to #9523 (comment)

Not an alternative

Alternative to the linked comment, not the PR entirely.

---

I will rebase my PR

You have a shortcut towards that, as I already cut out the relevant part of it here #9523 (comment)

• git fetch origin 467061e && git reset --hard FETCH_HEAD .

-- you could also try the same with the merged state (c5fc39d) but GitHub has no clean way to represent dependent PRs so that'd just be a mess.

But probably best to wait until discussion on this one settles down, as my opinion has no guarantee of being selected as correct.

[aravindavk]

You have a shortcut towards that, as I already cut out the relevant part of it here #9523 (comment)
-- you could also try the same with the merged state (c5fc39d) but GitHub has no clean way to represent dependent PRs so that'd just be a mess.

No issues, I can handle the rebase. Thanks

[straight-shoota]

Should we mention the alternative predicate method: exc.os_error.enoattr?

[asterite]

Please don't merge this yet. We'll discuss it in the next core team meeting. And we'll probably go with the non-portable way.

[oprypin]

How did the meeting go? 😅

In any case, seems like the label "pr:on-hold-do-not-merge" is more appropriate than this unique one

[HertzDevil]

^ What happened to this? I was thinking if POSIX signals should do this same thing on Windows MSVC

[straight-shoota]

I don't recall whether this was ever discussed in a Core Team meeting, or whatever the outcome was 🙈

[HertzDevil]

Signal currently lists all the possible flags in the documentation instead. The docs generator runs on a Linux host (evidenced by the documented value of Crystal::DESCRIPTION), so the API docs list all Signal members that are defined on Linux, and Signal::BREAK is missing.

I don't know if the same approach is viable for Errno because this enum is much larger than Signal.