make OP_AELEMFAST work with negative indices

Use aelemfast for literal index array access where the index is in the
range -128..127, rather than 0..255.

You'd expect something like $a[-1] or $a[-2] to be a lot more common than
$a[100] say. In fact a quick CPAN grep shows 66 distributions
matching /\$\w+\[\d{3,}\]/, but "at least" 1000 matching /\$\w+\[\-\d\]/.
And most of the former appear to be table initialisations.
add aux_flags field to HVs with aux struct

Add an extra U32 general flags field to the xpvhv_aux struct (which is
used on HVs such as stashes, that need extra fields).

On 64-bit systems, this doesn't consume any extra space since there's
already an odd number of I32/U32 fields. On 32-bit systems it will consume
an  extra 4 bytes. But of course only on those hashes that have the aux
struct.

As well as providing extra flags in the AUX case, it will also allow
us to free up at least one general flag bit for HVs - see next commit.
gv_check(): use aux flag rather than IsCOW

Currently the SVf_IsCOW flag doesn't have any meaning for HVs,
except that it is used in the specific case of gv_check() to temporarily
mark a stash as being scanned. Since stashes will have the HV_AUX fields,
we can use a flags bit in the new xhv_aux_flags field instead.

This then potentially frees up the SVf_IsCOW for use as a new general flag
bit for *all* HVs (including non-stash ones).
Document what the gv_check() function does
speed up (non)overloaded derefs

Consider a class that has some minimal overloading added - e.g. to give
pretty stringification of objects - but which *doesn't* overload
dereference methods such as '@[]'. '%[]' etc.

In this case, simple dereferencing, such as $obj->[0] or  $obj->{foo}
becomes much slower than if the object was blessed into a non-overloaded
class.

This is because every time a dereferencing is performed in pp_rv2av for
example, the "normal" code path has to go through the full checking of:

  * is the stash into which the referent is blessed overloaded? If so,
  * retrieve the overload magic from the stash;
  * check whether the overload method cache has been invalidated and if so
    rebuild it;
  * check whether we are in the scope of 'no overloading', and if so
    is the current method disabled in this scope?
  * Is there a '@{}' or whatever (or 'nomethod') method in the cache?
    If not, then process the ref as normal.

That's a lot of extra overhead to decide that an overloaded method doesn't
in fact need to be called.

This commit adds a new flag to the newish xhv_aux_flags field,
HvAUXf_NO_DEREF, which signals that the overloading of this stash
contains no deref (nor 'nomethod') overloaded methods. Thus a quick check
for this flag in the common case allows us to short-circuit all the above
checks except the first one.

Before this commit, a simple $obj->[0] was about 40-50% slower if the
class it was blessed into was overloaded (but didn't have deref methods);
after the commit, the slowdown is 0-10%. (These timings are very
approximate, given the vagaries of nano benchmarks.)