Move composer state mgmt from its app to the state provider

[d13]

Today, the ComposerApp acts as the state manager between the child components and the state provider/context. As a result, a lot of event bubbling and prop-drilling must occur for mutating state and updating state, which can cause rendering performance issues.

General state and state mutation should be centralized within the Composer's state provider class. This should result in:

• any remaining state in the ComposerApp will be around its local state or for DOM-specific purposes
• the CommitsPanel and DetailsPanel components getting their state directly from the state provider and can update independently without triggering large lifecycle changes on the ComposerApp