General merit workflow

This is an explanation of how does merit process reputation starting from an HTTP request made to an endpoint with associated rules[1]. It's meant for merit developers, not directly helpful for application set up.

1. Merit sets an application-wide after_filter, which creates a merit_action for the request if that controller/action pair has associated rules.

2. Controller after_filter tells MeritAction class to process it's unprocessed activity (will typically be the newly created merit_action). It can be done synchronously (default) or as a background job.

3. merit_action asks a judge to grant reputation, given the sash and rule in question.

4. The judge will grant or remove badges and points from it's sash according to rule[1] conditions.

[1] Reputation rules are set in the application via the DSL defined in files rules_{badge|points|rank}_methods.rb

What is each migration/DB-table meant for? On merit internals

Merit installs following tables to the app:

1. merit_actions is meant for internal merit usage. It is the log of "meritable" actions and who triggered them, so that then it can compute per action if points or a badge is to be granted to someone.
2. sashes defines the Sash model, which has a one-to-one relationship with your "meritable" resources. It has some internally used methods, and it avoids join models.
3. badges_sashes is a relation table between Badges and "meritable" resources. There's only one join model per app, no matter how many meritable resources it has, thanks to the Sash model. Sash indirection should be invisible for the application, and should not be used.
4. merit_score_points holds an entry for each point granting/removing, with a num_points integer and an optional log string. They belong to merit_scores which is an indirection between meritable resources and points, meant to hold (still to do) different categories for which a meritable resource may be scored.
5. It also adds new attributes on each resource: sash_id and level.

Class diagram