Take the array key into account when checking whether an unnamed KEY matches in Datab...

Take the array key into account when checking whether an unnamed KEY matches in DatabaseTableChangeProcessor

The reproducer effectively matches d7f721d6f920d66f75102723b504d89e57a8c9ff, except that the KEY
is unnamed.

Previously the update would silently fail to do anything. Now the update fails
loudly, because it attempts to create another index with an existing name. This
is no different behavior compared to an INDEX collision of two unnamed indices
`(a, b)`, `(a, c)`. The developer will be clearly alerted of this issue and can
take appropriate measures to avoid it, e.g. by using explicit names.

see #4434