refactor gv_add_by_type

refactor gv_add_by_type

gv_add_by_type was added in commit d5713896ec in 5.11.0 . Improve
gv_add_by_type by making it return the newly created SV*, instead of the
the GV *, which the caller must deref both the GV head to get svu and
then deref a slice into the GP, even though it already derefed svu and GP
right before, to figure out whether to call gv_add_by_type in the first
place. The original version of this patch had gv_add_by_type returning a
SV ** to ensure lvalue-ness but it was discovered it wasn't needed and not
smart.

-rename gv_add_by_type since it was removed from public api and its proto
 changed
-remove null check since it is impossible to pass null through GvAVn(),
 and unlikely with gv_AVadd, null segvs reliably crash in the rare case of
 a problem
-instead of S_gv_init_svtype and gv_add_by_type using a tree of logic/
 conditional jumps in asm, use a lookup table, GPe (e=enum or entry)
 enums are identical to offsets into the GP struct, all of then fit under
 0xFF, if the CC and CPU arch wants, CC can load the const once into a
 register, then use the number for the 2nd deref, then use the number again
 as an arg to gv_add_by_type, the low (&~0xf) or high (<<2) 2 bits in a
 GPe can be used for something else in the future since GPe is pointer
 aligned
-SVt_LAST triggers "panic: sv_upgrade to unknown type", so use that value
 for entries of a GP which are not SV head *s and are invalid to pass as
 an arg
-remove the tree of logic in S_gv_init_svtype, replace with a table
-S_gv_init_svtype is now tail call friendly and very small
-change the GV**n to be rvalues only, assigning to GV**n is probably a
 memory leak
-fix 1 core GV**n as lvalue use
-GvSVn's unusual former definition is from commit 547f15c3f9 in 2005
 and DEFSV as lvalue is gone in core as of commit 414bf5ae08 from 2008
 since all the GV**n macros are now rvalues, this goes too
-PTRPTR2IDX and PTRSIZELOG2 could use better names
-in pp_rv2av dont declare strings like that VC linker won't dedup that, and
 other parts of core also have "an ARRAY", perl521.dll previously had 2
 "an ARRAY" and "a HASH" strings in it due to this

before VC 2003 32 perl521.dll .text 0xc8813 in machine code bytes after
.text 0xc8623