To-do tests for method/isa/overload updates and overloading

Changes to methods, @ISA, or overload settings should affect objects
that are already blessed into the class.

Currently, objects that existed before any overload settings were in
place do not do overloading at all (bug #112708).  Objects that were
blessed when overload settings were in place are not affected by
changes to methods or @ISA until another object is blessed into the
same class.
Move SvAMAGIC flag from object to stash

By putting the flag on the stash, we can allow the overloaded status
of all objects of a particular class to change without having to
change the flag on every object (which would require traversing arenas
or keeping caches).

This partially fixes bug #112708, in that objects that existed before
their class had any overloading will start working after overloading
is introduced if other objects are blessed into that class.

Without blessings of other objects, they still don’t work yet.  The
fix for that is yet to come....

This was also a good excuse for deleting a comment that contained two
typos.  :-)
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
overload.t: Tests for no overload "fallback"

This is something I almost broke in trying to fix a bug in ‘no
overload "fallback"’.
Make overloaded classes inherit fallback

Before this commit, only classes that had no overloading defined could
inherit the fallback from other classes.  If a subclass wanted to
override a single overload setting, it would have to specify the fall-
back value explicitly, to avoid implying fallback=>undef.

We do this by separating the fallback value from overloadedness
itself, so it is possible to have a class that is overloaded, but with
no fallback value.

Previously, the ‘()’ stash entry was used for two purposes.  It had a
sub in it so it could be found using usual method lookup mechanims.
The failure to find any such method would be taken for efficiency’s
sake to mean that there was no overloaded, and the search for methods
could end early.  The scalar slot contained the fallback entry itself.

To preserve the effiency, we still use &{"()"} to indicate that there
is overloadedness.

Fallback now uses its own entry, named ‘(fallback’.  Since it
has to be special-cased anyway, there is no need to add it to
regen/overload.pl.
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.