Don’t check PL_amagic_generation in Gv_AMG

Because version.pm is now part of perl, PL_amagic_generation is always
non-zero, so there’s no point in doing that check.
Don’t incr PL_amagic_generation in universal.c

In boot_core_UNIVERSAL, there is no need to increment
PL_amagic_generation to indicate that there are classes using over-
loading.  The previous commit removed the only use of it that required
it to be non-zero for overloading to work.
sv.h: Add HvAMAGIC macros

These are the only Hv* macros in sv.h, so I may be putting them in the
wrong place.  However, they are very closely related to those that
immediately precede them.
sv.h: Turn off AMAGIC flag in Gv_AMG

This makes no functional changes.

If a stash has its AMAGIC flag on, then when the overload caches are
updated we can turn off the flag if it turns out that there is no
overloading.

Gv_AMG is the easiest place to unset this flag, as Gv_AMupdate has
‘return 0’ in more than one place.

This is for efficiency’s sake, as an object that inherits overloading
but then loses it through @ISA changes will still have to go through
extra checks due to SvAMAGIC returning true.

This also offsets an inefficiency to be introduced in later commits:
changes to @ISA will set the AMAGIC flag.
sv.h: define SvAMAGIC in terms of HvAMAGIC
gv.c: Check overload tables when overloading is used

Instead of checking whether overload tables are up to date only during
bless, do this check whenever using overloading.

This allows changes to methods and @ISA that affect overloading to
come into effect immediately, instead of requiring a dummy ‘bless[]’
to reset things.  (This does not yet apply to @ISA changes that cause
non-overloaded classes to start inheriting overloading.)

This fixes a bug brought up in ticket #112708, though the original bug
still exists.

Some tests had to change, but those tests were checking to make sure
that caches could go stale and still be used, which made no sense.
overload.t: Another to-do test for isa changes

Changing a non-overloaded class’s @ISA such that it starts inheriting
overloading should apply to objects already in that class, without
requiring an explicit ‘bless \$dummy’ to update things.
[perl #112708] Update overloadedness with ‘use overload’

Instead of setting a class’s overloaded (HvAMAGIC) flag when bless
happens, we should do it in ‘use overload’.  Otherwise, if a non-over-
loaded class gains overloading via ‘use overload’, existing objects
won’t get overloading until another object is blessed into the
same class.

Inherited overloading that is turned on due to @ISA changes still
won’t work yet.  That will come in a later commit.

Doing this via %OVERLOAD magic would require referencing
the stash from magic.  Since overload.pm already does
‘*{$package . "::()"} = \&nil’, triggering mro_method_changed_in,
the simplest approach is to turn on the stash’s AMAGIC flag in
mro_method_changed_in.  Since, if there is no overloading, the flag
will be turned off on the next attempted overload call (in Gv_AM in
sv.h), there should be noticeable slowdown.

I had to turn off HvAMAGIC in hv_undef, to prevent ‘Can't use anony-
nous symbol table for method lookup’ from occurring when stringifying
an object whose package has been undefined.
overload.t: Move some tests above ‘keep last’ test
Make @ISA changes update overloadedness

If a non-overloaded class begins inheriting overloading due to @ISA
changes, we need to set the overloaded (AMAGIC) flag on the stash to
indicate that.  Updating caches shouldn’t require a dummy blessing.
Increase $overload::VERSION to 1.19
Correct comment typo in overload.t
Reset fallback completely on ‘no overload "fallback"’

Before this commit, ‘no overload "fallback"’ would not undo the decla-
ration, making it as though it had never happened (the way it does
with ‘no overload '+'’, etc.).  Instead, it was equivalent to ‘use
overload fallback => undef’, making it impossible to revert to inher-
iting it from another class.
overload.pm: Don’t touch %OVERLOAD’s dummy entry

Now that mro_method_changed_in (triggered by the
‘*{$package . "::()"} = \&nil;’ assignment) causes overloadedness to
be checked the next time a overloaded operation occurs, it is not nec-
essary to trigger %OVERLOAD’s magic explicitly.

This also means that PL_amagic_generation is not incremented any more.
Unfortunately, we cannot eliminate it, as there are XS modules that
expect to increment it themselves to mark their caches as stale.
Make ‘no overload’ also warn about invalid args
sv.c: Don’t fiddle with AMAGIC in sv_bless

Since overloading itself now checks whether caches are up to date, and
since changes to the stash (@ISA, methods) turn the flag on and over-
loading itself turns the flag off when it can, sv_bless no longer
needs to deal with it at all.
sv.c: Don’t do SvAMAGIC_off in sv_setsv_flags

This has been useless since the flag was moved to the referent in com-
mit dd2eae66.  dstr is undefined by the time this statement is reached
if it was a reference.
sv.c: Don’t do SvAMAGIC_off in newSVrv

This has been useless since the flag was moved to the referent in com-
mit dd2eae66.  rv is undefined by the time this statement is reached
if it was a reference.
Don’t magicalise %OVERLOAD

It’s not necessary any more, now that mro_method_changed_in sets the
AMAGIC flag on the stash.
Annihilate ‘A’ magic

How ironic!  Overloading is called ‘A’ magic internally all over the
place, because of the letter used as its magic type.  But now it does
not even use that magic.

I left a comment in mg_vtable.pl, so that future maintainers will have
some clue as to what AMAGIC means.