Add some list-related NIFs

[mat-hek]

Credit: @FKubisSWM, @TheSobkiewicz

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

[bettio]

First question here: did you notice a relevant performance increase by replacing these functions with a native implementation?
Can you leave some information about this here (and maybe it might be a good idea to add this to the commit message, so we can have some further context about why this change has been done).

One style comment: let's use shorter commit subject / PR title (as encouraged in general with git).

[mat-hek]

Hi @bettio, generally our goal is to make AtomVM more compatible with OTP, and these functions are extensively used in OTP, but implemented in the BEAM as NIFs. Thus, I think it's worthwhile to have them as NIFs regardless of whether the performance improvement is significant. However, I did a simple benchmark with lists:member:

      haystack = Enum.to_list(1..200_000) ++ [:needle]

      t = :erlang.system_time(:millisecond)
      true = :lists.member(:needle, haystack)
      true = :lists.member(:needle, haystack)
      true = :lists.member(:needle, haystack)
      true = :lists.member(:needle, haystack)
      true = :lists.member(:needle, haystack)
      :erlang.display(:erlang.system_time(:millisecond) - t)
      :ok

and on my machine the benchmarked part takes around 40 ms before these changes, and 25 ms after, so it's quite big improvement IMO

[pguyot]

Indeed BEAM has at least lists:member/2 and lists:keymember/3 as NIFs as OTP28.

For what it's worth, I ran the benchmark on jit branch: 52ms with JIT and 97ms without. The longest part definitely was generating the haystack.

[mat-hek]

@pguyot I wasn't aware you're working on JIT, that's great news! Generating the haystack takes very long indeed, not sure why, but I only measured the 'lists:member` part. BTW, keyfind and keysearch are NIFs too.