Check for unsaved changes prior to deleting an interface

[critzo]

This issue was originally submitted to the Commotion website by @andygunn in post-testing of the 1.0 release.

When using the Add and Delete buttons for adding and removing interfaces, if a user adds a new interface, then changes her mind and uses the Delete button to remove it, but did not actually Confirm and Apply the interface, the default configuration is actually deleted. We should check on the feasibility of saving and applying queued changes before the Delete command is executed, to ensure a user is deleting the change they intended. See the use case description originally submitted below.

We were checking a few settings in:
Basic Configuration -> Network Settings -> Mesh Networks

The "Add" button was clicked, then the new interface was deleted right away with the "Delete" button, before clicking save. The admin panel then takes the user to a confirm changes dialogue, at which point the Status menu comes back up.

The Commotion mesh interface appears to be completely removed at this point, and it isn't clear how to re-create it.
Please describe what behavior you expected:
The expected behavior is to remove the second mesh interface that was created by clicking add. It isn't clear that this interface hasn't been initialized, and that clicking delete will actually remove the original mesh interface.

In order to fix the issue, we had to reset the device to defaults in the Advanced menu tree.
Please describe what behavior you experienced that you believe is wrong:
It isn't clear why additional mesh interfaces are set up in this manner. There isn't a way to select other network interfaces (such as Ethernet), it only defaults to the single wireless connection in the device.

Recommend removing the "Add" and "Delete" buttons from this menu completely, as it is quite simple to destroy the Commotion mesh connection.