Add elem combinator to API

[emilypi]

This PR adds the elem combinator to the API.

[hvr]

So I'm slightly on the fence about this; for one, elem is trivially definable in terms of any

elem c = any (==c)

and I'm not sure if this meets the https://wiki.haskell.org/Fairbairn_threshold standard.

Fwiw, there's appears to be lack of evidence that this is needed insofar as nobody seems to have missed having this trivial definition in Data.Text for over a decade...

However, there's precedent in e.g. Data.ByteString.elem and Data.Vector.elem which do provide this standard verb; so for the sake of API symmetry/uniformity among vector/list-ish data-structures, it'd make sense to add this (redundant) verb, as there might be some level of expectation of it existing.

Also, in principle, elem could be implemented more efficiently in some cases where fusion doesn't matter via a memmem(3) substring search on the utf16 encoding.

[emilypi]

So I'm slightly on the fence about this; for one, elem is trivially definable in terms of any

My reasoning is precisely that this is a part of the API that's defined for every other string-like object or list-like container. It passes the Fairbarn test on account of it's expected to be there, eminently useful (perhaps less so for text), and it homogenizes the APIs across libraries. You may object to it on the bounds that it's a small addition, but it was surprising that it was not already.

[emilypi]

@hvr updated and it should be ready to go

[emilypi]

@phadej too, if you're more active

[emilypi]

@hvr rebased to master so we should be able to just merge with no problems

[Lysxia]

This looks good to me (conclusion: we want this for uniformity with other collection-like APIs). Ping @haskell/text for another approval to merge this.

[Bodigrim]

Adding a test would be nice.