[benchmark] Fix Existential.Array.Mutating Setup Overhead

[palimondo]

Mask the setup overhead from copying of existential array in Existential.Array.Mutating by increasing the workload (5x). This way the overhead of copying is less than 5%.

Remove the misguided attempt at solving this problem with grabArray method - there is no way to avoid this overhead because every sample should start from a fresh copy.

Note: these benchmarks are tagged .skip, so they will not show up in the report.

[palimondo]

@swift-ci please smoke test

[palimondo]

@swift-ci please benchmark

[swift-ci]

Performance: -O

TEST	OLD	NEW	DELTA	RATIO
Regression
DataAppendDataLargeToLarge	17200	24000	+39.5%	0.72x (?)
SuffixArrayLazy	4	5	+25.0%	0.80x (?)

Performance: -Onone

TEST	OLD	NEW	DELTA	RATIO
Improvement
TypeFlood	148	138	-6.8%	1.07x (?)

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

[palimondo]

@eeckstein Since these benchmarks are disabled for performance testing on commits (are not tracked), I'll go ahead and merge this without review, since the build and tests were successful.