undivert() behavior

[Eric Blake]

I noticed another incompatibility with traditional implementations.  POSIX 
requires undivert to reject arguments with non-numeric characters (hence our 
extension of treating those as a filename and diverting the file contents 
instead).  But since an empty string has no non-numeric characters, and since 
the empty string cannot be a file, we should treat undivert() as though it were 
undivert(0) (in other words, expand to the empty string, since diversion 0 is 
always immediately pushed to stdout).

$ /usr/ccs/bin/m4
divert(1)one
divert(2)two
divert

undivert(0)

undivert()

undivert
one
two

m4exit
$ m4
divert(1)one
divert(2)two
divert

undivert(0)

undivert()
stdin:5: m4: Cannot undivert : No such file or directory

undivert
one
two

m4exit

I will go ahead and patch this to match traditional behavior, where the empty 
string is treated as 0 (and hence a no-op) rather than a filename.  I also 
noticed this:

$ /usr/ccs/bin/m4
divert(-1)
undivert(0)
divert

m4exit
$ m4
divert(-1)
undivert(0)
divert
m4exit
$ m4 -dV
m4 debug: NONE: 0: input read from stdin
divert(-1)
m4trace:stdin:1: -1- id 1: divert ...
m4trace:stdin:1: -1- id 1: divert(`-1') -> ???
m4trace:stdin:1: -1- id 1: divert(...)
undivert(0)
m4trace:stdin:2: -1- id 2: undivert ...
m4trace:stdin:2: -1- id 2: undivert(`0') -> ???
divert
m4exit

Hmm - when we are discarding input, undiverting diversion 0 seems to hang the 
output engine!  Hopefully, this is also easy to fix.

-- 
Eric Blake