Bugs in `string:trim` when using nested strings containing binaries

[Maria-12648430]

Describe the bug
Minimal examples probably shows it best:

1> string:trim([<<"\r \n">>, []], trailing, [$\n, [$\r, $\n]]).
<<"\r \n">> %% wrong, trailing \n, should be <<"\r ">> or equivalent

2> string:trim([<<"\r \n">>, "\n"], trailing, [$\n, [$\r, $\n]]).
<<"\r \n">> %% wrong, still a trailing \n, should be <<"\r ">> or equivalent

3> string:trim([<<"\r \n">>], trailing, [$\n, [$\r, $\n]]).
<<"\r ">> %% this is right

4> string:trim(["\r \n", []], trailing, [$\n, [$\r, $\n]]).
"\r " %% this is also right

5> string:trim(["\r \n", <<"\n">>], trailing, [$\n, [$\r, $\n]]).
"\r " %% and this is still right

So the outline of the problem seems to be binaries in lists, followed by another element, and the binaries contain the starting character (\r here) of a grapheme cluster (\r\n here) in the trim-characters, but which is followed by something else (space here, not \n).

Since string:chomp calls trim internally, the same behavior also appears there. The problem seems to be rooted in the bin_search function, which is used in many more places, where similar bugs might surface.

Another interesting case is this one:

4> string:trim([<<"\r \r">>, []], trailing, [$\r, [$\r, $\n]]).
** exception error: no case clause matching []
     in function  string:cp_prefix_1/3 (string.erl:2182)
     in call from string:trim_t/3 (string.erl:1538)

5> string:trim([<<"\r \r">>], trailing, [$\r, [$\r, $\n]]).
<<"\r ">> %% this works and is right

The problem outline here is similar but involves trim-characters where one trim-character (\r here) is the first character of a grapheme cluster (\r\n here) that's also in the trim-characters.

To Reproduce
See code examples above.

Expected behavior
In a nutshell, all the above examples should yield equivalent results, <<"\r ">>.

Affected versions
OTP 29 and earlier, probably down to 20.0.