docs: policy for writing models

[Ivshti]

the business logic should be handled entirely in the model, especially everything including mutability

the more logic we have in the models, the less of a chance there is for a logic mistake in the view code

e.g. notifications: which video is a notification should definitely be handled in the model

some thing are borderline: e.g. whether to expose a is_still_loading property (rather than see if one of the groups is still loading); in this case, we should not add the extra property, cause different views might decide to render a separate loader for each group (e.g. if the UI design gets changed)

when there is data that is closely related to what we have in the model, but can be retrieved from the context, then do so, at the expense of an extra copy; for example, each item in CatalogFiltered should be paired with a Option<LibItem>; even though this can be retrieved by the view (from the context), do not resort to that this is borderline too cause it might cause extra bugs, because we have to keep one additional thing up to date; another case like that is using Notifications model in the library view; also addons, where we sometimes need info from the manifest (addon name, behaviorHints) but the model exposes it's url (through ResourceRequest)

---

Document Effects and how effects work, and that you can loop a msg back into the system (see #54) by doing Effects::one(futures::ok(msg))

[borasemiz]

I guess you guys decided not to write documentations after all :)