Add support for keyword lists in Access.key/2 and Access.key!/1

[tudborg]

This adds Keyword list support to Access.key/2 and Access.key!/1.

Original discussion in #15468

I'd like to move some of. the doctest into access_test.exs instead.
Access.key was only tested in doctests, but the other accessors have dedicated describe in access_test.exs,
but this is good enough for a discussion around the feature. :)

[tudborg]

I wasn't sure how defensive to be in the returned accessor function.
Currently I'm assuming the container is a keyword list if:

• the container is a list
• the key is an atom

I could be more defensive and require the container is either [] or [{key, _} | _] when is_atom(key).
or less defensive and just assume that a list is a keyword list.

I'm currently raising an ArgumentError if the data isn't what is expected, but maybe that should be a RuntimeError instead like in Access.key! (at least those two raises should be the same type)

I think it is important that regardless of container type, the raise is the same
(i.e. not BadMapError + FunctionClauseError depending on container)

Thoughts?

[josevalim]

We are usually not that defensive when it comes to keywords. We may error but it is not a guarantee.

Note the pop/3 commit is still there. :)

Thoughts on the key changes @sabiwara?

[sabiwara]

Overall looks good, but we might need to be slightly more defensive in the following case or bugs might slip:

iex> put_in([1], [Access.key(:foo)], :bar)
[{:foo, :bar}, 1]

The raw key fails with a non-optimal error but at least it fails:

iex> put_in([1], [:foo], :bar)
** (FunctionClauseError) no function clause matching in Keyword.get_and_update/4