Implement support for TDataSet buffering (like VCL DBGrid does).

Currently, TVirtualDBData class is not using buffering. TDataLink BufferCount is set to the maximum dataset RecordCount, so there is no buffer (the whole dataset is needed)

This has a long list of problems. Firemonkey TGrid also uses this workaround via livebinding classes.

The correct usage is setting BufferCount to a "window" or "subset" of rows, making the dataset work in buffer mode, asking the database server the needed rows when necessary.

Steps to fix:

1) A new TVirtualDBData "Mode" property or something similarly named, to optionally set on/off this "buffered" mode (eg: Automatic, Buffered, All)

2) In buffer mode, set ILink.BufferCount to a big-enough number (for example 200) which must be bigger than the maximum number of rows visible at the same time (ie. on a big 4K resolution screen, how many rows max can we paint?)

3) TRows.Paint method should detect we are in "buffered" mode, maybe asking a new virtual function in TVirtualData abstract class, returning True (or the buffer size), when buffer mode is enabled.

When True, cells should be painted in row-by-row mode always.  (Column-by-column paint loop cannot be used).

Also, the first row to paint should not be calculated based on the current TeeGrid1.Rows.Scroll.Y pixel value. It should be an internal private variable that is always maintained, eg:  TeeGrid1.Rows.Scroll.FirstRow : Integer

The paint loop then, from first row to last row, should pass TVirtualDBData with the FirstRow and the loop index too.

Current row-by-row paint loop should be converted to a "while" loop, that should call Data.Next until EOF, instead of using a "for row..."


4) Vertical scrollbar should work in "lazy" mode (see this issue : http://bugs.teechart.net/show_bug.cgi?id=1768 )

5) TeeGrid1.Selected.ScrollToView should be True in buffer mode, this means the current selected row must be always inside grid bounds when scrolling, as the dataset buffer cannot include rows outside the visible ones.

6) Special consideration for append / insert rows (records) and maybe row deletion.

7) Also a dataset refresh (from a new trip to the database server), might return a completely different number of rows, or a complete different "window" (buffer) of rows, so the grid should consider rows "volatile"

8) A possibly needed new feature too, is to always paint the first row (the topmost row) exactly at 0 pixel position, to avoid painting it partially occluded by the (optional) grid header or grid top edge.