Fix protect Array#map against concurrent mutation

[straight-shoota]

The optimized implementation of Array#map is vulnerable to concurrent mutation. This patch replaces it with a less efficient but safer variant. It's basically the same as Enumerable#map except that the new array's capacity is initialized with the current size.

Performance degrades by this less-efficient implementation, but it should be acceptable for the sake of safety.

A better performing alternative for highly optimized workloads is Slice#map.

10
old map_with_index  31.41M ( 31.84ns) (± 7.95%)  80.0B/op        fastest
new map_with_index  22.60M ( 44.25ns) (± 9.54%)  80.0B/op   1.39× slower

100
old map_with_index   6.65M (150.35ns) (± 7.28%)  480B/op        fastest
new map_with_index   3.55M (281.79ns) (± 5.26%)  480B/op   1.87× slower

100000
old map_with_index  16.64k ( 60.09µs) (± 6.02%)  391kB/op        fastest
new map_with_index   6.81k (146.93µs) (± 4.54%)  391kB/op   2.44× slower

100000000
old map_with_index  11.62  ( 86.04ms) (±10.12%)  381MB/op        fastest
new map_with_index   6.19  (161.46ms) (± 4.90%)  381MB/op   1.88× slower

Benchmark Code

require "benchmark"

class Array
  def safe_map_with_index(offset = 0, & : T, Int32 -> U) forall U
    ary = Array(U).new(size)
    each_with_index(offset) { |e, i| ary << yield e, i }
    ary
  end
end

[
  Array(Int32).new(10, &.itself),
  Array(Int32).new(100, &.itself),
  Array(Int32).new(100_000, &.itself),
  Array(Int32).new(100_000_000, &.itself)
].each do |ary|
  puts ary.size

  Benchmark.ips do |bm|
    bm.report "old map_with_index" do
      ary.map_with_index { |e| e * 3}
    end
    bm.report "new map_with_index" do
      ary.safe_map_with_index { |e| e * 3}
    end
  end
  puts
end

Fixes #15161

[BlobCodes]

Is this fix really worth the reduced performance?

Java solves this by throwing a ConcurrentModificationException when modifying the amount of values in the array while using methods like map.
I think that could be an alternative solution.