(Issue #821) Respect edge blacklist, lower limit

Data obtained by /data/edges can be quite large; limit the data to 5000 edges for most edge types. Also, respect the %LJ::FORCE_EMPTY_SUBSCRIPTIONS configuration option.

This patch also fixes a potential race condition and adds functionality to the member_userids and member_of_userids functions to request a limit to the number of userids returned.

---

This patch still needs testing and I'll be doing that after I make this PR. I would appreciate eyes on this pull request, however - in particular, I'm wondering if it's clear what I'm doing with using and assigning to the various lists inside the parameters to the load_userids calls, or if I should use a more verbose but more readily understandable form. (The reason I use lists in the first place is because there's the remote possibility of a race condition otherwise, if the user list changes between the first and second calls to the *_userids subs.)

I also had to add 'limit' support to member_userids and member_of_userids as they didn't support that before now. I haven't added this support to maintainer_userids and moderator_userids; if it's felt that they should have it, I'll add it in.
I would normally agree with you and have done it already here, though the main reason I didn't do it in this case is that the sub being called here caches the results in memcache, and I assume that it would be undesirable to store a truncated result in memcache, since I don't know what else may want to use that data, and whether such things would need access to the full list.

(Additionally, for the /data/edges API, it's more about the bandwidth than the load; /data/edges can quite easily generate an output of about 2MB with the right community at the moment, which makes it a bit of a potential chokepoint.)