Fixes nvaccess#17502

Summary of the issue:
In nvaccess#15386, support was added for numRows and numCols on braille displays. Setting numCells explicitly would also set numCols.
In nvaccess#17011, we're much more relying on numCols and numRows.

For the eco braille and Lilli drivers, numCells was implemented by overriding _get_numCells. However this way, the setter of numCells would never be called and therefore numCols would always be 0.

Description of user facing changes
Fix braille for Eco Braille and Lilli displays.

Description of development approach
When calculating display dimensions on the braille handler, when display.numRows is 1, use display.numCells instead of display.numCols. This accounts for cases where numCells is implemented and numRows/numCols are not.
Worked around the ZeroDevisionError when getting windowStartPost on a buffer
Initialize _windowRowBufferOffsets to [(0, 0)] instead of [(0, 1)]. The latter suggests that the window contains one cell, which is not the case. @michaelDCurran you might want to check this.

Fixes nvaccess#17502

Summary of the issue:
In nvaccess#15386, support was added for numRows and numCols on braille displays. Setting numCells explicitly would also set numCols.
In nvaccess#17011, we're much more relying on numCols and numRows.

For the eco braille and Lilli drivers, numCells was implemented by overriding _get_numCells. However this way, the setter of numCells would never be called and therefore numCols would always be 0.

Description of user facing changes
Fix braille for Eco Braille and Lilli displays.

Description of development approach
When calculating display dimensions on the braille handler, when display.numRows is 1, use display.numCells instead of display.numCols. This accounts for cases where numCells is implemented and numRows/numCols are not.
Worked around the ZeroDevisionError when getting windowStartPost on a buffer
Initialize _windowRowBufferOffsets to [(0, 0)] instead of [(0, 1)]. The latter suggests that the window contains one cell, which is not the case. @michaelDCurran you might want to check this.

Follow up of #17011
Slightly related to #17635, as this oversight was found there

Summary of the issue:
In #17011, `braille.filter_displaySize` was deprecated, but there was not yet a mechanism in place that logs warnings about usage of the deprecated extension point.

Description of user facing changes
Warnings in the log when `braille.filter_displaySize.register` is called.

Description of development approach
1. Added an optional keyword argument `_deprecationmessage` to `HandlerRegistrar`. If set, it will be logged when a handler is registered.
2. Removed remaining handlers in core, changed them into handlers for `filter_displayDimensions`
3. Unit test expansion, missing tests for `filter_displayDimensions`

Testing strategy:
Tested that a warning is logged when registering 

Known issues with pull request:
None known