(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.
Who cares about 2MB? That's overall pretty tiny, many of the images we host are at least that large and we serve those just fine.

If you did push the limit all the way down, you'd have to make the caching handle truncation. But I don't suggest that, I think that having it at the very top (in the controller) is the right call since enforcing a random limit at this midpoint seems odd to me? (Although I could be convinced?)