update-manager shouldn't use modal dialogs

Binary package hint: update-manager

update-manager currently uses modal dialogs for everything except the main list-of-updates window. This is very bad from a usability point of view.

Conceptually, the only defensible use of modal dialogs is to demand the user an answer without which the program cannot continue, and only in response to an “abnormal” situation. The only example in network-manager where this would be acceptable is when an critical error occurs during the update. (Note that not _all_ errors must be displayed like this.) Any other use means the work-flow of the application is badly designed.

Practically, the modal dialogs cause many usability problems beyond the conceptual jarring:
1) No input can be given to the main window, including window-manager commands. For instance, if the main window is maximized when an update is started, it cannot be minimized or moved until the end, except with a global "show desktop" command. (Also, if the window is in full-screen mode, as I often leave it, the panel—where the show desktop button usually is—might be hidden and unaccessible.) Note that this can be doubly annoying in small-screen cases, like a PDA.
2) Some window managers sometimes place modal windows below the main window. This can make the program completely unaccessible.
3) If the dialog somehow happens to arrive somewhere different than above the main window (dual-screen is the likeliest case, but not the only possibility) it can be very non-obvious why the main window is in the “inactive” state.

I propose the update-manager be switched to a “workflow” system, similar to how wizards work:

a) Don't show the modal dialog with the "Starting update manager" progress bar. It doesn't ask the user for anything, so it needn't be a dialog, nor modal. Instead, put a progress bar at the top of the main window (or just replace its content with the progress bar).

b) Asking for the password is necessarily a global-modal for security reasons, that can't be avoided.

c) Don't show the “downloading” progress bar in a dialog. It doesn't expect user info (canceling is exceptional) so it needn't be a dialog. Also, it can display lots of info (if the user wants per-file progress info), so a small window is not very useful. Instead, switch the main window to a “downloading” page, as a wizard would do.

c') If a non-critical download error occurs (e.g., some packages couldn't be downloaded, but the install might continue), don't show a dialog. Instead, ask the user if the install should continue. (Replace the progress bar with the question; leave the download details accessible as before.) Otherwise continue to the next step automatically.

d) Don't show the “installing software” in a dialog. The same arguments apply as above. Use a different page to show install progress, with the details below.

d') Don't stop for noncritical errors.
d'') Don't return to the first page when the install is done, even if successful. (1) there usually is nothing interesting there, since we probably already installed everything and (2) there is often something interesting in the install “terminal”, we should allow the user to look at it at leisure. Provide a big fat warning message if there were errors, but don't put up a dialog. Just put buttons for exiting and returning to the package list.