Use IVSIZE not HAS_QUAD to enable "long long" formats in sv_vcatpvfn_flags().

Without this, enabling HAS_QUAD on 32 bit IV systems causes a lot of test
failures. Potentially those failures could be addressed, but it seems like
a lot more work for little gain.
Use IVSIZE not HAS_QUAD to enable 'q' and 'Q' formats in pack.

Whilst the code for 'q' and 'Q' in pp_pack is itself well behaved if enabled
on a perl with 32 bit IVs (using SvNV instead of SvIV and SvUV), the
regression tests are not. Several tests use an eval of "pack 'q'" to
determine if 64 bit integer support is available (instead of
$Config{ivsize}), and t/op/pack.t fails many tests. While these could be
fixed (or skipped), unfortunately the approach of evaling "pack 'q'" is
fairly popular on CPAN, so the breakage isn't just in the perl core, and
might also be present in code we can't see or submit patches for.
The choice of 7 or 13 byte extended UTF-8 should be based on UVSIZE.

Previously it was based on HAS_QUAD, which is not (as) correct.
Eliminate POPq, POPuq, TOPq, TOPuq, dPOPqv, dTOPqv, qPOPuqv, dTOPuqv.

These shortcut macros are unused in the core, and unused by any code on CPAN.
If any XS code we can't see *is* using them, it will now fail to compile, and
can easily be fixed by replacing the macros with their expansion.
Merge fixes needed to build with 32 bit IVs and HAS_QUAD defined.

However, don't actually eliminate the #undef HAS_QUAD for 32 bit IVs, as
the costs (in CPAN breakage) look to be higher than the gains.
(See RT #119753 for more detailed analysis.)