Normalize rules for proposals vs rules for features

[zloirock]

It's described here: #145 (comment)

For different use cases, it could be good to have different ways to forbid some specific features.

It could be good to have a way to forbid all features from a proposal in one line, in one rule.

However, this way has some problems. For example, the Set methods proposal case. Early Safari / Bun implementations add methods from this proposal... but missed Set.prototype.difference, oven-sh/bun#2309. After that, when the proposal was already available in some engines, the algorithm of Set.prototype.intersection and the order of result were changed. Etc.

So it could be good to have also a way to forbid some specific features from proposals.

I see it as a rule for a proposal and rules for each feature. As an option, it could be an option with the features list for proposal rules - however, it's not so intuitive as separate rules with names of features.

Also, I think that the approach should be normalized even for existent rules since for something we have rules for proposals like es-x/no-object-map-groupby, for some other proposals - rules for separate features, like es-x/no-array-prototype-toreversed or es-x/no-array-prototype-with.