Early draft on how to persist Presenters

based on #50

Background

Presenters should be able persist their state so they can reuse their state after the process has been killed. Android provides a simple API (#onSaveInstanceState()) where Bundles can be saved and restored when a new Activity instance gets created (#onCreate(saveInstanceState)). This is already possible with a few lines of code and no further library APIs are required.

The onSaveInstanceState solution has some weaknesses:

• The Presenter lives longer than the Activity and can manipulate its state after onSaveInstanceState() got called. The mutated state never gets saved.
• Bundle is part of the Android SDK and cannot be used in unit tests (only mocked)

Solution

As a solution the Presenter gets a public method to save its current state persistState(). The state must be returned by TiPresenter#onSavePersistentState(): byte[].
persistState() can be called at any time; when onSaveInstanceState gets called, later or earlier even when no Activity instance is available.
This triggers a TiPresenterSerializer responsible for the persistence which can be exchanged with other implementations.
Unlike Activity#onCreate() the persistanceState will not be a parameter of TiPresenter#onCreate(). This would be a breaking API change and doesn't provide any value compared to a method getPersistentState(): byte[]

The default implementation of TiPresenterSerializer will store the state in a single file per Presenter in <appfolder>/cache/TiPresenterStates/. We cannot detect when a state isn't required anymore, therefore we cannot cleanup those files properly. Some other mechanism must be applied to prevent an always increasing cache folder. I recommend a fixed cache size by deleting the oldest states like OkHttp.

TODOs

• Create a TiBundle and use it instead of byte[] returned by getPersistentState() for an easy way to save primitives by key and automatically write all into one byte[]. Androids Bundle throws DeadObjectException when created after the Activity is destroyed and cannot be used. May be also a problem for #51
• Implement cache cleanup
• don't prefetch the persistentState at the first launch of a presenter
• document all the things
• make sure the default presenter serializer doesn't break unit tests

Open Questions

• The default presenter serializer implementation requires a Context and cannot be statically initialized like TiConfiguration.DEFAULT right now. Maybe initialize it in a ContentProvider? Or set the default implementation from the hosting Activity/PresenterInstructor when nothing is defined in config?

@vRallev @k0shk0sh please review