(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.
Since this limit is not passed down to the next level where we actually hit the data store, it's entirely fake. I would prefer to either plumb the limit all the way (which seems like the wrong call here) or just handle the limit at the top.

I.e., asking it to return only 5000 edges doesn't really buy you anything when it's actually getting 50,000 from the backend. So we might as well make it filter at the very edge?