webadmin: Differentiate progress triggered by async operations

Since there's a lot of model code checking whether getProgress() !=
null, in which case methods return without doing anything (this was an
old workaround to avoid duplicate OK clicks), the new async events
would cause some bugs. This patch changes the mechanism to be more
conservative:

* It now doesn't touch the model side of things.

* "Manual" override is made possible even if originally the progress
was triggered by an async operation, i.e. if in some flow a developer
ever calls startProgress() on the model, an async operation will not
stop the progress.

Change-Id: I94b8a2eac59ac712f0e9744fa4bd84c66dd84c5a
Signed-off-by: Lior Vernia <lvernia@redhat.com>