[partition] defuse is-next-enabled

Both the KPMCore and the ChoicePage -- asynchronously -- were connected
to the nextStatusChanged() signal. So if the core said next was true,
that could end up communicated to the ViewManager, enabling the *next*
button in the UI.

Changing to the *erase* page generally triggers a KPMCore reload,
which later emits a `hasRootMountPointChanged()` signal, once the
layout is applied and the disk gets a root mount point. So we'd
get a `true` from KPMCore, which -- because it was connected directly
to the signal to the VM -- would override any other considerations.

Hook up both signals to an intermediate slot that just recalculates
whether the next button should be enabled, based on the state
both of the Choice page and whatever else.

src/modules/partition/gui/PartitionViewStep.cpp

@@ -107,8 +107,8 @@ PartitionViewStep::continueLoading()
     m_waitingWidget->deleteLater();
     m_waitingWidget = nullptr;
 
-    connect( m_core, &PartitionCoreModule::hasRootMountPointChanged, this, &PartitionViewStep::nextStatusChanged );
-    connect( m_choicePage, &ChoicePage::nextStatusChanged, this, &PartitionViewStep::nextStatusChanged );
+    connect( m_core, &PartitionCoreModule::hasRootMountPointChanged, this, &PartitionViewStep::nextPossiblyChanged );
+    connect( m_choicePage, &ChoicePage::nextStatusChanged, this, &PartitionViewStep::nextPossiblyChanged );
 }
 
 
@@ -348,6 +348,11 @@ PartitionViewStep::isNextEnabled() const
     return false;
 }
 
+void
+PartitionViewStep::nextPossiblyChanged(bool)
+{
+    emit nextStatusChanged( isNextEnabled() );
+}
 
 bool
 PartitionViewStep::isBackEnabled() const

src/modules/partition/gui/PartitionViewStep.h

@@ -78,6 +78,9 @@ private:
     void initPartitionCoreModule();
     void continueLoading();
 
+    /// "slot" for changes to next-status from the KPMCore and ChoicePage
+    void nextPossiblyChanged( bool );
+
     PartitionCoreModule* m_core;
     QStackedWidget*   m_widget;
     ChoicePage*       m_choicePage;