JLI_ReportErrorMessageSys has a number of issues, which came up when reviewing https://github.com/openjdk/jdk/pull/9749.

- The windows variant prints message, then extra-info if available. But the unix variant prints first extra-info, then message. It would be good if that were standardized.

- Windows variant intermingles GetLastError and errno, which is incorrect. Both can be set, from independent API calls, and without knowing which API was called we don't know which to display. Note that CRT functions may also call Win32 APIs, and (less probable) vice versa. There is no way for JLI_ReportErrorMessageSys to know which is the right code. Therfore we need a way for the caller to indicate which error to show. Either by having separate APIs (e.g. JLI_ReportErrorMessageSysCRT and JLI_ReportErrorMessageSysWin32) or via an additional parameter. As it is, in its current form, we may call JLI_ReportErrorMessageSys for a CRT error and it may accidentally display a Win32 API error lingering around from some earlier unrelated Win32 API call.

- On macOS, we have two call sites of JLI_ReportErrorMessageSys where the errno text is already provided as part of the message by the caller, and therefore would be printed twice.

- Visual separation of message and extra-message: the rule is apparently that the caller has to provide the separation formatting: "it's up to the calling routine to correctly format the separation of messages" (of message and extra info). This leads to very awkward call sites (see https://github.com/openjdk/jdk/pull/9749). The problem is that the extra info may not be available: errno or GetLastError may report 0. That cannot be predicted by the caller, therefore the caller should not have to think about it. The function should append the extra-info only if available, omit it if it is not available, and take care separation itself.