Remove Array.set_at

[radeusgd]

Pull Request Description

Implements https://www.pivotaltracker.com/story/show/182879865

Important Notes

Note that removing set_at still does not make our arrays fully immutable - Array.copy can still be used to mutate them.

Checklist

Please include the following checklist in your PR:

• The documentation has been updated if necessary.
• All code conforms to the
  Scala,
  Java,
  and
  Rust
  style guides.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed: Enso GUI was tested when built using BOTH
    ./run ide dist and ./run ide watch.

[JaroslavTulach]

It'd be more consistent if append_vector_range used the same parameters as take and drop. Otherwise perfect - I am very glad Array.set is gone!

[radeusgd]

I decided to remove these, since our arrays are meant to be immutable by design.

Curiously, still, Array.copy is able to overwrite contents of our arrays even if they report being 'unmodifiable'. Very weird. @JaroslavTulach do you think this may be a bug? I assume it should be somehow possible to create a completely read-only array which does not support writing (possibly can be done by wrapping it in an UnmodifiableList).
OTOH we are actually currently relying on this, as we use Array.copy for implementing many of our Vector operations.

[radeusgd]

The removal of set_at is done and it seems to more or less work.

However many tests started failing for a separate, though related, reason. The reason is however a bug that was already there, it was just much more rare because most of our arrays used to be Enso Array type. Now, many operations like Vector.map (which relies on Vector.new) will return Vectors backed by polyglot arrays. Many of our builtins actually expect an Enso Array and if they get a polyglot array they panic reporting an unsupported type. Interestingly, the same will happen with our ArrayOverBuffer type, since it also is not a subclass of Array. This is bad and I think we need to discuss how to proceed with that. cc: @JaroslavTulach @hubertp @jdunkerley

A temporary fix would be to write a function

ensure_enso array =
    case array of
        Array -> array
        _ ->
            new_array = Array.new array.length
            Array.copy array 0 new_array 0 array.length
            new_array

which ensures that an Enso array is used, and use it everywhere we pass arrays to such builtins, as there aren't that many places that do so. But this is definitely not an ideal solution, I think we need to rework how builtins expecting arrays work so that they accept any kind of array, not just the Enso ones. Maybe we can just replace Array with Object[] or modify our builtins DSL to add such additional specializations to make it work? (cc: @hubertp / @kustosz)

[radeusgd]

As @hubertp pointed out, the issue may be partially fixed by #3628. I think the issue may still be worth discussing - because we would still be living with 3 types of arrays which are not interchangeable (not a very polyglot state of things), but at least vectors constructed from polyglot arrays would not cause such trouble as what is causing our current test failures, so that would be a step in the right direction. Still, for example the ArrayOverBuffer is incompatible with Array and we may need to revisit this to make it work properly.

I think it will make most sense to put this PR on hold until #3628 is integrated and we can discuss the right way to proceed.