refactor ExtensionManagerViewModel.

This is to prepare for further refactoring in support of consistent view
between multiple views.

In order to support recognizing when updates were available and providing both the registry and installed views with accurate information about the user having previously opted to remove or update an extension, I was planning to push that functionality down into ExtensionManager itself. So, "idsToUpdate" or remove would be on ExtensionManager and the common ExtensionManagerViewModel would just call through to ExtensionManager to prepare the data for the view.

Ultimately, I would expect both a RegistryViewModel and InstalledViewModel to be alive at the same time.