Add way to define multiple status options that share a single limit

Now that the dust is starting to settle on #359412: Move code for signup limits per status per node into a submodule, and in discussion with a few folks about possible use-cases for signup_status_limit, it's clear that there's an additional feature that would really let this functionality shine in the real world...

It'd be great if there was a way for an admin to declare that multiple status options are sharing a single limit. For example, let's say you had a situation where folks can pay for a slot at an event. You might have 30 total slots at the event. However, you need a separate status for "Paid/registered" and "Payment pending". But, to prevent over-subscription, and trying to charge people for a slot that's not going to be there, you really want both of those to count towards the 30 slot total.

However, maybe you want a limit of 5 signups in the "Invited" status, 10 on the "waitlist", and unlimited "Can't attend" replies... So, you can't just use a global limit and say only paid + pending count towards the limit, and everything else is unlimited. However, for the purposes of the limits, you don't care if the signup is "Paid" or "Payment pending" -- you just want to ensure that you never have more than 30 signups in either status.

I was thinking about the UI for this, and it could be something like the views2 UI when you're configuring the headers and columns for a table view. When you're defining the per-status limits, there'd be a new column in the table for which status's limit a given status should use. By default, each status would use the limit for itself. But, if you selected a different status, the limit text box would disappear. So, if you look at the attached screenshot of the views UI, the "Field" column would be "Signup Status", the "Column" column would be something like "Status limit to use", and the "Separator" column would be the "Limit" column. See what I mean? ;)

I've got a few ideas on the schema and backend changes to support this. Shouldn't be *too* terrible.

Continuing the above example, you'd basically define your limits just like you do now, but the "Payment pending" status would be configured to use the "Paid" limit instead of defining a limit of its own. Make sense?

I believe this system would provide an arbitrarily flexible way to define whatever kind of limits you might need. It might even solve #582522: Claiming arbitrary resources when you signup although that seems like an even more nasty complication. :(

Thoughts?
-Derek