Fix #3276: Remove two major defects in posixlib utsname.scala

[LeeTibbert]

Fix #3276.

I theory, this PR, is not a candidate for backport. However, the code in SN 0.4.n is
so broken that a backport could not be accused of being a breaking change.

Two major defects in utsname are removed:

1. the uname method can not longer write to Scala Native memory that it
   does not "own".

2. fields in the utsname structure after the first, say nodename or version now
   contain valid data as returned by the OS. Previously they had most likely been
   empty strings.

An entry was made in the 0.5.0 changelog which should cover this PR and the prior
PR #3264 by mox692.

My personal thanks to mox692 for shining the light on utsname and causing
detailed review.

[LeeTibbert]

The one failure is in Windows initialization code and has nothing to do with the
substance of this PR.

All else is Green, like Kermit.

[LeeTibbert]

@mox692
If you have time & interest, could you take a look at this PR and tell me what you think?
It is alway nice to have a second pair of eyes on code. Thank you. I understand if the press of
events take you elsewhere. I have a bit of that going on myself.

Is it consistent with what you set out to do?

[ekrich]

I was wondering if we have to model the struct as a set of CArrays? It seems that if the POSIX spec says the byte array is null terminated that it might just make sense to model it as CStrings. To me this seems like it would avoid many of the foot shots and all the casting issues. Using a good Scaladoc could explain it. I know this is not the exact mapping of the spec but do we have to do that if we have good reason?

[mox692]

@LeeTibbert
Thank you for updating
Sure, I'll look at it after work today :)

[LeeTibbert]

Eric, thank you for the discussion. It is always worthwhile to ask if one is inside
the box because that is the better place to be.

I think that leaving the CArray declarations as is is the the better way to go. Staying
close to both the Open Group description and to what Linux & macOS actually allocate
reduces complexity and divergence.

I put a note in the utsname.scala file describing how one might convert the null-containing
CArrays into proper Scala Strings. I think that will make the easier to use.

[mox692]

Thank you @LeeTibbert.
I left just one question, but other part looks ok to me.

[mox692]

If I understand correctly, shouldn't we write
SIZEOF_FIELD(struct utsname, sysname)
instead of
SIZEOF_FIELD(struct scalanative_utsname, sysname) here?

[LeeTibbert]

@mox692 You are absolutely correct. Good catch, thank you.

Fixed now.