The dde.c tests succeed on Windows and the DDE callback registered is
set to trigger on all messages it gets. Thus it looks like Windows
doesn't calls the callback in that case.

The code for the child windows works now for the standalone windows as well.

Also handle the case where TMP and TEMP are not defined.

EM_FINDTEXT should be able to find end of line characters, but currently
it doesn't.

The two functions ME_FindItemAtOffset and ME_RunOfsFromCharOfs were almost
identically used, since ME_FindItemAtOffset was always used to find a run.
The only difference was how they returned the offset within the run for an
end of paragraph run.

For ME_FindItemAtOffset it would return the next run if it was in between \r
and \n. ME_RunOfsFromCharOfs would instead return an nOffset of 0 for end
paragraph runs.  This subtle difference introduced bugs, so I decided to
avoid having special case in this function when creating this patch, and
instead let the caller handle this case.

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.