Since around the 5.10 era, `Perl_sv_setsv_flags` has unconditionally set
`SvPOK_only(dsv)` in the `SVp_POK` branch. The associated comment reads:

    /* Whichever path we take through the next code, we want this true,
       and doing it now facilitates the COW check.  */

Things have changed since 5.10 though, in particular using the `‎SVf_POK`
to distinguish between a value that started off as a string from one that
was originally an integer/float and later stringified.

This commit:
* Removes the `SvPOK_only(dsv)` in favour of `SvOK_off(dsv)` and hoisting
  the copying of `sflags` over.
* Transforms the subsequent now-redundant `SVf_POK` toggles into asserts
  (to help reduce) the chance of inadvertent behaviour changes.

`Perl_sv_setsv_flags` is a hot function that contains liberal sprinklings
of `SvOK_off()`. This commit changes two instances, where the operand SV
cannot possibly be using the OOK hack, to do direct flag twiddling instead.

`SvOK_off()` does two things:
1. Toggles off some flags:
    SvFLAGS(sv) &= ~(SVf_OK|SVf_IVisUV|SVf_UTF8)

2. Checks for use of the OOK hack and undoes it:
    ((void)(SvOOK(sv) && (sv_backoff(sv),0)))

At least some compilers seem to struggle to figure out when `SvOOK(sv)`
cannot be true and to then elide the call to `sv_backoff()`. This is
desirable when:

1. ssv & dsv are both lower types than SVt_PV and cannot support OOK
2. inside a block following a conditional check that OOK is not in use

In the two cases identified, the flag toggling is now done explicitly.

Perl_newSVsv_flags_NN creates a fresh SV that contains the values of its
source SV argument. It's like calling `new_SV(dsv)` followed by
`sv_setsv_flags(dsv, ssv, flags`, but is optimized for a brand new
destination SV and the most common code paths.

The intended initial users for this new function were:
* Perl_sv_mortalcopy_flags (still in sv.c)
* Perl_newSVsv_flags (now a simple function in sv_inline.h)

Perl_newSVsv_flags_NN prioritises the following hot cases:
* SVt_IV containing an IV
* SVt_IV containing an RV
* SVt_NV containing an NV
* SVt_PV containing a PV

It will then check for:
* SVt_NULL
* SVt_IV containing a UV
* SVt_LAST

The helper function S_newSVsv_flags_NN_PVxx is called for everything else.
It will use Perl_sv_setsv_flags as a fallback for rare or tricky cases.

S_newSVsv_flags_NN_POK is a dedicated helper for string swipe/COW/copy
logic and is called from both Perl_newSVsv_flags_NN and
S_newSVsv_flags_NN_PVxx.

With these changes compared with the previous commit:

* `perl -e 'for (1..100_000_0) { my $x = { (1) x 1000 }; }'` runs about 20% faster

* `perl -e 'for (1..100_000_0) { my $x = { ("Perl") x 250 }' runs about 40% faster

* `perl -e 'for (1..100_000_0) { my $x = { a => 1, b => 2, c => 3, d => 4, e => 5 }; }'`
   is a touch faster, but within the margin for error

* `perl -e 'for (1..100_000_0) { my $x = { a => "Perl", b => "Perl", c => "Perl", d => "Perl", e => "Perl" } ; }'`
   runs about 17% faster

Perl_newSVsv_flags has become just a stub around Perl_newSVsv_flags_NN.
For callers where the source SV* is NULL, not having to call a
function in sv.c to immediately return is very desirable.

Besides using the just-introduced faster path for SV copying, this
allows the check for SV_GMAGIC to be pushed into the called function
without having to worry about SV leaks.

Two additional micro-optimizations are also in this commit:
* A pointer to xav_fill is cached for use in the loop. This can
  be used directly to update AvFILLp(av), rather than having to
  get there from av's SV* each time.

* The value of the loop iterator, i, is directly written into
  xav_fill, rather than getting the value in that slot,
  incrementing it (to get the same value as i), and writing it back.