Introduce component architecture and menu and shortcut components

This merge request is a request for comments on the component architecture plan. The plan is:

• Each application in FreedomBox is implemented as a class called App.
• This class is composed of many components (Component) each responsible for a small area of the app. Components could manage a menu item, a shortcut, Apache configuration, systemd service, firewall ports etc. This will make an App very readable as interactions between components is non-existent.
• Components are highly reusable across apps.
• Components are created during the initialization of the app and (mostly) kept for the entire life type of the app.
• App implements operations like enable, disable, is_enabled. This provides a uniform interface for performing many operations in a generic way on each app (this will simplify a lot of code).
• App's implementation is simply delegated to components. app.enable() is nothing but for component in app.components: component.enable(). This will eliminate most of the code we have in each app's __init__.py. This reduction in repetition will also eliminate a source of many bugs.
• Ultimately, most of the applications will be implemented by just creating a derived App class which has __init__() in which components are added. Most other methods won't be necessary unless some custom logic for the app is needed.
• The process of creating components can be made declarative and moved to manifest file. App will simply add itself components by looking at a manifest file. This will bring us very close to adding apps without any coding.