New feature: set a note as favorite (star/unstar)

[korelstar]

Setting a note as favorite was already introduced on the server side (owncloud/notes#248 and nextcloud/notes#4) and can be used to stick important notes to the top of the list in order to find them easier (cp. #92). My changes here introduce this feature for the android app.

Beside this, I did some necessary refactoring in the NotesListViewActivity/ItemAdapter: (re-)loading the list of notes is now done in an AsyncTask and reuses the ItemAdapter instance (instead of creating a new instance on every refresh). As a result, the list of notes does not jump to the top anymore (cp. #118).

The implementation of the favorite feature is straight forward and has no special treatment for old(*) server app versions (i.e., versions that do not support the favorite feature). As a result, if a user sets a note as favorite, the star disappears after the next synchronization with an old server app. This behavior can be improved with some effort:

a) activate the feature only on demand => add a checkbox to the settings activity and only show the favorite feature, if this checkbox is activated

b) detect server features automatically => like a), but instead of setting the checkbox by the user, the app has to check if the server uses an appropriate version. This requires changes in the server API (e.g. an info URL which returns a JSON with the version number) and its unclear, at which point of time the app should check this in order to detect updates of the server app.

c) activate the feature, but keep the local state if the server result does not contain any information about favorites => requires some changes in the app; problem: when the user updates the server app he/she will lose the local favorites setting (the server favorites will overwrite the local favorites). In order to improve this, some more effort is needed, e.g. a new DB column is required, which notices if the local meta data (i.e. favorite setting) was changed and not yet synchronized. Therefore, this solution requires the most effort (I didn't see this in my first estimation: #92 (comment)).

As an overall consequence, I would leave this as is -- for now. If a better downward compatibility is required, then we can do this in a separate commit/pull request.

(*) today, "old server app" means also the current official version of the server app. For now, the favorite feature is only in the git master branch and is waiting for the next release.

[stefan-niedermann]

TL;DR: Merged!

Great work @korelstar as usual and thanks for the detailed documentation.

I agree with you in all points: c) is the preferred option. While no one has time to implement this, the current state is okay. I assume i will release v0.10.0 after the next server-app-version has released (+ some time for bugfixing and testing).

Assuming everyone keeps his instance up2date, we won't have problems with down-ward-compatibility.
What we could do at this point:

@Henni Can you tell us, how you are dealing with down-ward-compatibility? Which versions do you support? Only the current?