EM_GETTEXTRANGE allows the start character offset and end characters
offset to be used to specify the range of text to retrieve.  If the
start offset is in the middle of an end of paragraph run (i.e. \r\n),
then it should only retrieve the characters after the specified
character offset.

EM_GETTEXTRANGE should be able to get part of the end of paragraph run,
for instance just the line feed in a carraige return line feed pair.

I found that ME_FindItemAtOffset and ME_CursorFromCharOfs are used
almost identically, except for how they handle a character offset that
is between a carriage return and line feed.  In this case
ME_CursorFromCharOfs sets the cursor's run offset to 0, but
ME_FindItemAtOffset instead returns the next run which is what was
causing ME_LINELENGTH to incorrectly return the length of the next
line.

Previously this wasn't properly tested for, since all the lines had
text of the same length, so it wasn't properly testing to see which
line length it was getting.

riched32.dll does preserve the carriage returns and line feeds unlike
later versions of the richedit control, however the tests previously
missed the fact that a sequence of carriage returns followed by a line
feed (e.g. \r\r\r\n) can actually cause multiple paragraph breaks.

Several carriage returns followed by a line break were being handled as
a single paragraph break, when actually native richedit controls may
count this as several line breaks.

cryptui: Export all selected certificates when requested from the certificate manager, not just the first one.