Remove BOM-discarding code from MVM_string_utf8_decode()

This code is unreachable on a platform where char is signed, because there
utf8[0] will be between -128 and and 127 inclusive, and hence never equal to
0xEF. (ie x86, x86_64). On a platform where char is unsigned, the code is
reached, and it kills the Rakudo build. Specifically, this happens because
it munges strings being deserialised, with the particular problem string being
the character U+FEFF, which is used in pre-compiled NQP code. Deserialising
what should be a 1 char string U+FEFF as a 0 char string causes a very strange
"Could not locate compile-time value for symbol Whatever" error when
compiling the Perl 6 setting. Oh the strange side effects of bugs...

If BOM-nomming is needed, it should be in I/O specific code, and only at the
start of files, not in the general-purpose NFG conversion routines.
MVM_string_utf8_decode() should take a MVMuint8 *, not a char *

Conceptually, UTF-8 is sequences of Octets, which are unsigned, so use an
unsigned type.
Move the assignment to repr_data->attribute_offsets[cur_slot] later in compose()

We need it later to deal better with alignment for platform portability.
Splitting it into a distinct commit makes it easier to show that this part
of the change introduces no regressions.
P6opaque must handle C structure member alignment, just like CStruct does.

In particular, on some platforms MVMint64 has 8 byte alignment, which means
padding may well be required to correctly map to how the C compiler lays out
structs.