If the needle supplied to array_search() was a destructed object,
array_search() would convert it to (PIKE_T_INT,NUMBER_DESTRUCTED)-type 0
in-place.

Since array_search() is sometimes called with the needle residing in
another array - for example when ORing arrays - this would introduce
PIKE_T_INT items into such arrays without reflecting this in said
array's type_field.

If the type_field would then later on (still) only have BIT_OBJECT set,
we would call free_object() on the thus introduced PIKE_T_INT when
freeing array items, leading straight to a segmentation fault.

In some cases the array optimizer replaced UNDEFINED values
with zeroes.

Setters expect to be called when the corresponding variable is modified...

This behaviour caused Roxen's test-suite to fail due to change triggers
not being called.

This was sort of done before, but it first assigned the lvalue
to 0, then assigned it back to the array once done.

This new version is about 2x faster, improving the "append array"
benchmark by about 60%.

It more or less works as one would expect now.

Make it easier to keep track of state in the visit_*() API
by tracking when we start and stop visiting things.

All the visit_*() functions and macros should now propagate the
argument extra.

All the visit_*() functions now have all arguments.

Also unifies the two branches of apply_array().

This is to simplify renumbering of the types.

It now simply returns the array element (if it is a string, that is).

This especially helps when you have arrays with objects with `< and
`== operator overloading, where the constant is also changed
dramatically.

Also, it is now enough to have == operator overloading to get - to
work (given that there is at most one object in the array getting
items removed.)

Replace uses search_array, which in turn calls
check_array_for_destruct.  So, if you had an array where all elements
were replaced by the replace containing at least one object replace()
was O(n^2), not O(n).

In general check_array_for_destruct is rather unneeded, since the
comparison functions already checks for destructed objects, but I
guess that it might cause objects to be free:d slightly sooner.

When using array implode with zero elements it was possible to write the delimiter
into the newly created string too many times, resulting in a buffer overrun.
This bug has been introduced by commit 2f27ebab.

Since array.c is the only place the is_more_than_one_bit function is used, and it is, unlike many of our macros, suitable for inlining, inline it.

This was a regression from 3140378d.

The stable sort function masks it out, so that stable sorting work together
with the previous commit.