Enable MICROPY_PY_ARRAY_SLICE_ASSIGN on SAMD21

[deshipu]

The following code:

a = bytearray(b'abc')
a[1:2] = b'123'

works just fine on MicroPython and CircuitPython on the ESP8266, but fails with

TypeError: 'bytearray' object does not support item assignment

on the M0 boards. This is the fastest way to copy a fragment of a byte array (since it uses memcpy in C), but since it doesn't work consistently on all ports, I can't use it in my libraries. It would be nice if all ports supported it.

[dhalbert]

Turning on MICROPY_PY_ARRAY_SLICE_ASSIGN takes something like 384 to 576 bytes to include. I got different measurements based on trying to remove it from the Express build or add it to the non-Express build. It's a pretty Pythonic feature, and I think we could squeeze it in by lowering -finline-limit and/or seeing how big things are after the ASF4 port.

[gpshead]

I just noticed that this feature was missing on the non-express builds as I tried migrating some code to a smaller board. I'd love to see it there. If ultimately not, would it be possible to update the error message?

Currently it was something along the lines of Error: bytearray index assignment not supported. (paraphrased, my uc isn't connected at the moment). This was confusing as this isn't index assignment, it is slice assignment. But even improving the error message would consume more string space...

The workaround for a common case is a (presumably slow) manual loop:

Before:

a[start:end] = data

After:

# Assuming len(data) == end-start.
# Does not deal with expanding bytearray a if end-start would go beyond its bounds.
k = start
for b in data:
  a[k] = b
  k += 1

If you could even support just the case of slice assignment into a preallocated fixed buffer without reallocation/resizing that would be fine for my use case (I generally try to avoid reallocs)

[dhalbert]

Current measurements say this costs 400 bytes. I guess I'd choose those over #384 (add .decode) if I had to choose just one because it's more awkward without it. As with #384, we need to consider our storage budget in future releases.