Add typechecker handling for put_elem

[lukaszsamson]

This PR adds missing handling for put_elem.

The initial implementation and tests in d6213f5 was heavily based on existing implementations of insert_element and delete_element. However, I later discovered and reproduced in tests some soundness issues that affected both setelement and insert_element and delete_element which were fixed in commits 1c58013 and 328f1fc
Summary of issues:

• Tuple.insert_at/3
  • dynamic inserted value caused %{dynamic: :badindex} / %{dynamic: :badtuple} return instead of propagating the atom value
  • out of bound insert into dynamic closed tuple returned dynamic(none()) instead of :badindex - Already addressed in Tuple operations performance boost + fix logic bug #15376
• Tuple.delete_at/2
  • off by one in dynamic closed tuple, returned same size instead of size - 1 - Already addressed in Tuple operations performance boost + fix logic bug #15376
  • out of bands on dynamic closed was not returning :badindex
  • negative constraint on deleted index was preserved

  difference(tuple([atom(), atom()]), tuple([atom([:a]), term()])) |> tuple_delete_at(0)
  

  instead of dropping to tuple([atom()]) - Already addressed in Tuple operations performance boost + fix logic bug #15376

Also I noticed invalid warnings emitted for negative indices affecting all tuple ops:

    warning: expected a tuple with at least -1 elements in Tuple.insert_at/3:
        Tuple.insert_at({1, 2}, -1, :x)
    the given type does not have the given index:
        {integer(), integer()}

Fixed in 1c58013

@gldubc Note this PR partially overlaps with #15376 so you may want to include my changes into yours

I can split it into smaller PRs if this one is too big

AI use disclosure

Assisted-by: Claude Opus:4.7
Assisted-by: GPT:5.5

Fixes #15375

Edit: Rebased and updated since #15376 is already merged

[gldubc]

You already did what I was going to suggest :D I agree with the tuple_insert_at changes in descr.ex.

I'm wondering about replace_at. It's true that, before, it couldn't be implemented via delete + insert, because delete was broken. But now, it should just work.

[lukaszsamson]

I wonder if dropping the static part is right here. insert_element does drop it while delete_element preserves

[gldubc]

insert_element should be changed to preserve it, this is a loss of precision

[lukaszsamson]

It sounds like something for a follow up PR

[gldubc]

I can take care of it.

[lukaszsamson]

Tests in 1819-1829 do not assert any new behaviour added in this PR but were failing pre #15376

[gldubc]

You can get rid of them, this was tested in the PR.

[lukaszsamson]

Tests in 1917-1925 do not assert any new behaviour added in this PR but were failing pre #15376

[gldubc]

Also tested in the PR, can remove. :)

[josevalim]

@lukaszsamson can you please break this into multiple PRs?

1. No need to implement tuple_replace_at, we will do that ourselves
2. Any soundness issue should be a separate PR/issue
3. For the negative index, a PR is welcome. However, it should not be handled in the descr, it should be handled in apply before we call the descr