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.
steal P5's unlink magic for windows, clear readonly flag when needed

When are file is meant to be deleted, and when we are have the privilegues
to clear the readonly flag, then we do that first before attempting to delete
the file. In case the file was not deleted we restore the original file flags.
Add lexical lookup lifetime hinting ops.

Allow us to convey that a given lexical lookup can be relied on to
always resolve to the same thing, or can be relied on to resolve to
the same thing per invocant type. The former is useful for setting
sub lookups, the latter for type variables. For now don't do anything
extra, but spesh will be able to improve on this.
Speculate some speculative optimization spesh ops.
Add slots related to logging things we saw.
Re-organize spesh to have log/specialize phases.

When we first decide to specialize, we now only go so far as creating
argument guards. There is a place for logging instructions to be added
(though none are being yet). This information will then be available
when we reach specialize time, to guide specialization.
Implement sp_log op.
Start inserting logging instructions.
Correct log slot marking.
Fix scoped/lifetimed lexical lookup opts.
Add missing write barrier after spesh.
getlexstatic_o optimization.
Be more careful with no-handler frames.
Better error on handler fixup failure.