RFC: Revise Store/Folder/Message interface

Originally, K-9 Mail's design for the Store/Folder/Message classes was based on the JavaMail API. Over the years we modified our classes a lot but never threw away the parts that didn't work well for K-9 Mail.

I want to change this. Specifically, I want 'modules' to return objects that contain exactly the data that is needed by the caller. And to avoid lazy-loading or additional requests as much as possible.

Some ideas:

• Get rid of LocalStore and LocalFolder. Treating the database like a remote store only causes us pain and requires
  lots of boiler plate code.
  • Create a new interface and refer to messages by its database ID instead of using MessageReference.
  • Hand specialized value classes to UI; containing only data necessary to render the UI.
• Extract a class from Message that contains state information (flags, server uid, folder, etc.). Message should
  only be concerned with storing the message data (header + body). This should also allow us to get rid of most if not
  all checked exceptions on Message methods.
• Simplify Store and Folder interfaces. We have very specialized needs for synchronization. All other use cases are
  secondary.
• The way we synchronize messages is rather specific to the Store type. We probably want to move away from Store
  feature flags to separate synchronization implementations.

Having a very specialized interface will make k9mail-library even less useful for others. Later, we probably want to extract another library with just the basic operations for remote stores. But for now that shouldn't be our concern.

I'd love to get everyone's comments on these ideas or even alternative suggestions on how to improve the current situation.

Start by mapping the Store, Folder, Message, LocalStore, LocalFolder, and MessageReference classes or interfaces in k9mail-library. Review the RFC and surrounding implementation to define an agreed interface redesign; this issue does not specify a concrete implementation or completion test.