[todo-mvp-dagger] DaggerAppCompatActivity - more downsides than benefits?

Biggest problem for me when using `DaggerAppCompatActivity` is that there is no good way of handling data in `savedInstanceState` object or some other configuration change behaviours.

In `AddEditTaskActivity`, `mIsDataMissing` is extracted from `savedInstanceState` and can be accessed through method `isDataMissing()`. This method must be public as it is called from `AddEditTaskModule`. It finally must be called by AddEditTaskPresenter using Dagger Lazy functionality in a specific place - in `takeView` method - because if it is called any sooner, that variable will not be set in `AddEditTaskActivity` at all.

Another example is `TasksActivity`, where filter type in `TasksPresenter` is set through contract `TasksContract.Presenter` method `setFiltering`.

I guess that there is no unified way of initializing `Presenter` class or handling various Android specifics, like configuration changes, saving instance state etc. Therefore, I think that `DaggerAppCompatActivity` usage brings more "mess" to the code than simply calling good old `inject` method on Activity's `onCreate` method, where custom module parameters can be set and finally passed to `Presenter`s constructor in a clear injection way.

Please correct me if I am wrong.

Start by reading AddEditTaskActivity, AddEditTaskModule, TasksActivity, and the presenter contracts mentioned in the report, then compare their saved-state and injection paths. The issue defines no concrete change or acceptance criteria, so a maintainer decision on whether to replace DaggerAppCompatActivity and which behavior to preserve is needed before implementation can be considered done.

Written by the indexing model from the issue text.