Update components list

Key:
C = clarification
F = fix to avoid common problems
S = simple change

Changes:

1. C - Rename "Miscellaneous" to "Project Maintenance"
2. F - Remove "Feature module support"
3. S - Add "Discussion Group Maintenance"
4. S - Add "Other"
5. C - Rename Provided Rules integration to "Provided module integrations"
6. C - Rename "Rules Engine" to "Rules Core"
7. C - Rename "Forms Support" to "Forms Support (D6)"

Justifications and Comments

1. Misc is a problem waiting to happen right off the bat. Any clarity issues in the component list leads to this as the default choice for some users. On the other hand, it's kinda lucky that when looking at the list of issues, this theme popped out to me.
2. There are more than 2200 issues and less than 30 are in this. Many of these are actually misfiled but many more other issues were originally misfiled here, so the obvious answer is to fold it into "Provided Rules integration"
3. We don't have a way to administer gdo/rules yet, and I've proposed a number of changes that currently only fit under Misc. It makes sense to me.
4. I'm not sure this is even necessary. With these changes, it might be possible to wait and see if new issues seem misfiled or if we nailed it and the total Rules user experience of "Hey! [this] needs to be changed, and its part of [that]."
5. It's just an odd wording for what it is. First, it being singular is off, imo, and second, it makes sense, but it's still hard to understand for a reason that's hard to describe. Also, I'm not sure that 'provided' actually outweighs the cost/benefit of its intended benefit. I think #1597880: Update Rules Issue Queue Guidelines will be a good way to clarify the difference between Rules' provided integrations versus modules that provide integrations. Personally, I don't see this is a major pain point in the issue queue. It's not often that people file issues in this queue that belong in another, and even when they do, they get other eyes first.
6. This one might be subjective, however the engine is, AFAIK, only one layer of the code (the deepest), and things like entity api integration and data calculation actions aren't part of the engine, but currently fit best in that component.
7. I don't actually like this change, but the current state of Rules Forms Support is kinda weird. Theoretically, there should only be the porting issue under Forms Support in D7, but then why even keep the component? Why not find some way to rework the location of the D6 issues and get rid of it completely? Like, why not move D6 forms support entirely into the other project, and then move all the issues over there two. The answer to that is obvious. But then again, why not merge the other project back into core and give that maintainer permission to commit to that module only. I know that a new major version is underway, so this might be a good time to consider that approach.

Better order:

1. Rules Core
2. User Interface
3. Provided Module Integrations
4. Documentation
5. Project Maintenence
6. Discussion Group Maintenence
7. Scheduler
8. Forms Support
9. Other

There might still be some low hanging fruit here aside from my observations. I propose we request additional feedback and figure out a deployment plan in the meantime, then make the change and move on to more interesting things.