V4's Date constructor fails to take account of variations in time-zone offset

qtdeclarative/src/qml/jsruntime/qv4dateobject.cpp's DateCtor::construct() can, if given a date (with no time), manage to return a date-time object late in the previous day: see QTBUG-54559.
This is unequivocally wrong.

When time is unspecified, the returned object should represent some time on the correct date; if we can reliably hit 00:00 on that date then we should do so; and we probably can do this, but we have to pay attention.

The present implementation assumes a fixed time-zone offset: DatePrototype::init() sets LocalTZA once and for all to the current time-zone offset, which is entirely inappropriate for use by functions UTC() and LocalTime() as the adjustment to apply at arbitrary times in the past or future. Time zones do, in fact change.

We need to make this code actually use QDateTime (which gets most of this sort of thing right) instead of hand-rolling its own crude approximations to something close to right.