Get rid of ‘Not a format reference’

This commit:

commit 2dd78f96d61cc6382dc72214930c993567209597
Author: Jarkko Hietaniemi <jhi@iki.fi>
Date:   Sun Aug 6 01:33:55 2000 +0000

    Continue fixing the io warnings.  This also
    sort of fixes bug ID 20000802.003: the core dump
    is no more.  Whether the current behaviour is correct
    (giving a warning: "Not a format reference"), is another matter.

    p4raw-id: //depot/perl@6531

added a check to see whether the format GV’s name is null, and, if
so, it dies with ‘Not a format reference’.  Before that, that message
occurred only for lack of a GV.

The bug mentioned is now #3617, involving write(*STDOUT{IO}).  write
puts an implicit *{} around its argument.

*{$io} has historically been very buggy in its stringification, so
this patch seems to have been working around that bugginess, by fall-
ing back to the ‘Not a format reference’ error if the name couldn’t be
determined for ‘Undefined format "foo" called’.

*{$io} was fixed once and for all in 5.16.  It now stringifies as
*foopackage::__ANONIO__.

I don’t think producing a completetly different error based on the
name of the GV (whether it’s "foo" or "") is correct at all.  And the
patch that made it happen was just a fix for a crash that can’t hap-
pen any more.

So the only case that should produce ‘Not a format reference’ is that
in which there is no format GV (fgv).

I can prove that fgv is always set (see below), and has been at least
since 5.000, so that ‘Not a format reference’ actually could never
occur before 2dd78f96d61c.  (Actually, XS code could set PL_defoutgv
to null until the previous commit, but everything would start crashing
as a result, so it has never been done in practice.)

gv_efullname4 always returns a name, so checking SvPOK(tmpsv) is
redundant; checking whether the string buffer begins with a non-null
char is not even correct, as "\0foo" fails that test.

Proof that fgv is always set:

The current (prior to this commit) code in pp_enterwrite is like this:

    if (MAXARG == 0) {
	gv = PL_defoutgv;
	EXTEND(SP, 1);
    }
    else {
	gv = MUTABLE_GV(POPs);
	if (!gv)
	    gv = PL_defoutgv;
    }

If the stack value is null (which actually can’t happen), PL_defoutgv
is used.  PL_defoutgv can’t be null.

At this point, gv is set to something non-null.

    io = GvIO(gv);
    if (!io) {
	RETPUSHNO;
    }

Here we only set fgv to IoFMT_GV(io) if it is non-null.  Otherwise we
use gv, which we know is non-null.

    if (IoFMT_GV(io))
	fgv = IoFMT_GV(io);
    else
	fgv = gv;
Use the same top format error for ""

See also the previous commit.

2dd78f96 added the ‘Undefined top format called’ message for those
cases where a GV doesn’t have a name.  That was a bug that used to
happen with *{$io}, which can’t happen any more.

The code that 2dd78f96 added ended up changing a zero-length name to
be treated the same way as no name.  It also checked the length by
cheating and checking the first character instead.

Now that we have support for embedded nulls, that logic ends up wrong
for names like "\0foo".  And there is no need to treat "" differently
from "foo" anyway.

So this patch restores things the way they were before 2dd78f96.

It also improves the tests for ‘Undefined format’.

Writing tests for ‘Undefined top format’ was quite painful, as that
error seems to leave the internal state out of synch.  I suspect
PL_formtarget needs to be localised, or the error just needs to come
earlier in pp_leavewrite.  But I’ll save that for later, or for Dave
Mitchell. :-)
Make UNIVERSAL::can treats str and num the same way