Version 3 proposal: Remove use_zero_index_for_rank_option

Is this ever really used in practice? My guess is no. Although it
could be left in as it's not necessarily a lot of code, but it
does remove some conditional paths.
Version 3 proposal: Store optional member data in a single hash

This has the benefit of not using a separate hash for every single
member's data. As is updated in the documentation, you can store
more data for a given member by, for example, encoding a Hash
in JSON. Not only will this save on Hash-splosion if using member
data in a leaderboard, it also means that when deleting a
leaderboard, we can also delete ALL of the member data at once. In
version 2.x, if using member data, you would have to go through and
delete the member data hashes individually. Yikes!
Version 3 proposal: Remove use_zero_index_for_rank_option

Is this ever really used in practice? My guess is no. Although it
could be left in as it's not necessarily a lot of code, but it
does remove some conditional paths.
Rebase from master
Version 3 proposal: Store optional member data in a single hash

This has the benefit of not using a separate hash for every single
member's data. As is updated in the documentation, you can store
more data for a given member by, for example, encoding a Hash
in JSON. Not only will this save on Hash-splosion if using member
data in a leaderboard, it also means that when deleting a
leaderboard, we can also delete ALL of the member data at once. In
version 2.x, if using member data, you would have to go through and
delete the member data hashes individually. Yikes!
Merge branch 'version-3-proposal-store-member-data-in-a-single-hash' of github.com:agoragames/leaderboard into version-3-proposal-store-member-data-in-a-single-hash
Version 3 proposal: Add a `:sort_by` option

As indicated in #29, the currently undocumented behavior of a
direct call to `ranked_in_list` is to do no sorting on the results.
The call was originally intended to be used to retrieve a list
of friends from a leaderboard. However, it would be useful in
certain situations to have the results sorted. This adds a
`:sort_by` option to that would be appropriate for the
`ranked_in_list` call to sort by either score (`:score`) or
rank (`:rank`) when returning results.
Version 3 proposal: Add a `:sort_by` option

As indicated in #29, the currently undocumented behavior of a
direct call to `ranked_in_list` is to do no sorting on the results.
The call was originally intended to be used to retrieve a list
of friends from a leaderboard. However, it would be useful in
certain situations to have the results sorted. This adds a
`:sort_by` option to that would be appropriate for the
`ranked_in_list` call to sort by either score (`:score`) or
rank (`:rank`) when returning results.
Merge
Merge branch 'version-3-proposal-store-member-data-in-a-single-hash' into version-3
Bump version to 3.0.0.rc1
Resolve conflicts from merge of version-3-proposal-remove-zero-index-for-rank
Resolve conflicts from merge of version-3-proposal-rank-by-option
Removes `:with_scores` and `:with_ranks` as valid options

* Removes `:with_scores` and `:with_ranks` as valid options.
* `rake test_rubies` will only test under 1.8.7 and 1.9.3 now.
* Update README for :sort_by option.
* Update CHANGELOG.
Correct version for CHANGELOG
Update CHANGELOG
No longer cast scores to a floating point automatically
Added rank_member_if to rank a member in the leaderboard based on execution of a conditional
Added NOTE on using lambda for the rank_conditional
Add leaderboard_options passed to rank_conditional lambda.