Create an activity context for activities.

Previously Robolectric would simply reused the application's ContextImpl as the base context for the activity. As new APIs are being added in R and S (getDisplay, isUiContext) this will not continue to work well for activities. Also in general having the activity context and the application context be different more closely aligns with how android platform works in practice and will improve the quality of tests.

This change produces a couple of notable differences with prior behavior:

Resources

For resources/themes/configuration/displaymetrics/etc tests would frequently simply modify the application context with the expectation that the activity would receive identical changes (because the context objects were the same). This change causes this pattern to not work in general. It tries to preserve the theme carrying across by initialising the activity theme to the application theme, which was a common pattern, however changes to the resources/theme after an activity has been created will not longer be reflected by updating the application context automatically. Instead tests will have to ensure that they properly call changeConfiguration() on the activity controller (which now produces behavior much more aligned with real android when combined with RuntimeEnvironment.setQualifiers by correctly either calling onConfigurationChanged or restarting the activity) or instead apply the updates directly to the activity context.

System services

Previously because the activity and application shared the same context acquiring a service from that context returned the same instance and subsequently allowed a test to acquire the shadow of a system service on the application context and assume that the activity would receive the same stateful shadow implementation. By creating an activity context the system service objects returned would naturally be different instances, resulting in different shadows with different state. Before we are able to enable the new behavior by default we'll have to ensure the service shadows are storing state globally when appropriate and not per instance.