BTextView::GetText is broken

[waddlesplash]

Calling Text(); works as expected -- you get a char* with all the text in the view. But calling GetText(buffer, BTextView::TextLength()); produces the same output only if the text was not modified since SetText was called. If it was modified, buffer will not contain the text the view shows, but rather the text as if the user had written it while in overwrite mode meaning the GetText() buffer will be filled only up to the size of whatever was passed to SetText as well as being erroneous.

A few OpenGrok searches show that nothing internal uses this, but it appears that at least some apps on HaikuArchives does...

[waddlesplash]

Tried some more and found some internal stuff using it: ​http://grok.bikemonkey.org/source/search?q=&refs=GetText&project=haiku

[waddlesplash]

OK, first dissection:

​BTextView::GetText calls ​the second prototype of TextGapBuffer::GetString¹ which does some simple math to figure out where to memcpy to/from. Meanwhile, ​the first prototype of TextGapBuffer::GetString also takes fGapCount and fGapIndex into account, and while I wasn't dealing with styled text here I don't think that's the case, the logic differences between the two don't feel right.

1: Why do we have two prototypes of TextGapBuffer::GetString? Due to the differences listed here I think some effort should be made to combine the two.

[waddlesplash]

Some insight from Jessicah:

<jessicah> mm, RealText() seems to reset the gap buffer, whereas GetString()
           avoids resetting the gap buffer
<jessicah> looks like the other GetString is some internal magic utility function
           used by other interface kit internals

[waddlesplash]

Oh, and ​BTextView::Text() works because it bypasses that logic for ​TextGapBuffer::RealText() which doesn't deal with ranges and concatenates the whole buffer.

[waddlesplash]

Duplicate of #8447.