Make sure that $log_id is set for all paths

See #147
Make plugin uninstall test check conditional

We should only check this if we aren’t running the module uninstall
tests.

See #144
Uninstall: move line out of the points types loop

It doesn’t need to be run for each points type.

Found while working on #148
Remove unnecessary title attributes

Fixes #129
Improve docs of wordpoints_show_admin_message

See #77
Move helper methods into the main test case

Moves the helper methods from the points unit test case into the main
test case, so they will be accessible in the ranks tests as well.

See #122
Add change log to modified file includes

See #144
Drop the rank tables before install for unit tests

See #122
Remove blog_id, site_id cols from user ranks table

We’ll use the ranks table to store this data instead of storing it in
both locations. It also decreases data duplication since this info will
only be stored once per rank, rather than for every user who has the
rank.

See #122
Change rank_id column name in rankmeta table

WordPress assumes that the object ID column in a meta table with be of
the form `{object_type}_id`. Because our object type is
`wordpoints_rank` in this case, the column name needs to be
`wordpoints_rank_id` instead of just `rank_id`.

It is possible to implement a hacky workaround instead, (which we do
for the points logs meta table,) but I’ve opted for this solution since
it is simpler.

See #122
Add initial ranks API

This will receive more iteration as the UI is built. Here is how the
API works:

The basic elements of the ranks component are of course the ranks.
These objects are stored in the ranks database table and are
represented within the code using the `WordPoints_Rank` class, which
parallels in many ways `WP_Post`.

Ranks may have metadata in addition to their basic fields. This is
stored in the rank meta table, and may be
added/updated/deleted/retrieved with procedural functions.

Ranks are categorized into different ‘types’. Each rank type has its
own extra metadata and rules for when a user can achieve that rank.
Each rank type is handled by a child of the `WordPoints_Rank_Type`
class. This will handle the display of the form fields for ranks of
this type to the user, as well as validating the ranks metadata before
they are saved/updated. It will also hook into actions to trigger
possible rank transitions for a user, and determines whether a user can
move up to a rank or not.

The rank types are registered with and contained in the
`WordPoints_Rank_Types` class, in much the same fashion that points
hook types are registered with the `WordPoints_Points_Hooks` class.

Ranks are also organized into ‘groups’. These are sets of ranks
arranged in an ascending order, like a ladder the user may climb until
they reach the top. Rank groups are represented by instances of the
`WordPoints_Rank_Group` class, and are registered with the
`WordPoints_Rank_Groups` class. Each rank group can contain ranks of
various types, but for a type to be used with a group it must be
registered with it using
`WordPoints_Rank_Groups::register_type_for_group()`.

See #122
Add a parent test case for the rank unit tests

See #122
Add a rank factory for the unit tests

See #122
Add a mock rank type for the unit tests

See #122
Re-add the points unit test case

Was accidentally removed in work on #122
Unit tests for the basic ranks API

See #122
Apply exclude users setting to top users query

See #150
Add unit test for excluding from top users

See #150
Add 1.6.1 change log

(cherry picked from commit 2ca2cc398b3f8a58781a6f302ba7f690fed03854)
Give doing_it_wrong() notice setting rank vars

The properties of the `WordPoints_Rank` objects are read-only, so we’ll
give a notice if something tries to set them.

See #122