TableModel

TableModel provides a QAbstractTableModel that can be used from QML with TableView.

Approach #1 "rows"

Current (unfinished) state as of writing can be seen here: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/types/qqmltablemodel.cpp?h=dev&id=b4ee855eb10cf9bfa44ce8e5de8f9ee6c5917764

In addition, there are some follow-up patches:

• https://codereview.qt-project.org/#/c/253255/
• https://codereview.qt-project.org/#/c/253234/
• https://codereview.qt-project.org/#/c/253509/

Approach #2: No "rows"

• We know we can't expect one data format/structure for rows; need to be flexible.
• We know we want settable rowCount + columnCount for prototyping and allowing use cases such as e.g. spreadsheets.
• roleDataLookPolicy (https://codereview.qt-project.org/#/c/253509/) is making things quite complex

So:

• Remove "rows" altogether.

 How the actual source JS data is stored and formatted is up to the user,

• rowCount and columnCount would then have to always be specified so that we know how many there are.
• "roles" allows the user to use their custom roles without us having parsed the rows data

 (currently we parse it up front using an expected format so that we know which roles are available):

   roles: [
       ["driverId"],
       ["code"],
       ["url"],
       ["givenName"],
       ["familyName"],
       ["dateOfBirth"],
       ["nationality"]
   ]

• Then we call roleDataProvider() unconditionally each time data() is called for a "new" index,

 and store that in our own well-formatted map/hash, so we don't need to call roleDataProvider()
 again for that index.

• As appendRow(), moveRow(), etc. would no longer take the row as an argument, they would need to

 be replaced with beginAppendRow()/endAppendRow(), etc.