Change our process to group stack trace rewriters and debuggers

[jkup]

We've been having a bit of discussion at the hackathon and I'd like to be more transparent with our thinking. We've been looking at the scopes proposal and as it nears completion, it will be our first proposal to go through our process. A few things occurred to us:

1. We should really try to establish a closer relationship with more stack trace rewriters. @nicolo-ribaudo said he would reach out to some folks and see if they've had any chance to look at our proposal yet.
2. Our "constituencies" language of "generators", "debuggers" and "Error monitoring tools" is proving a bit difficult to work with. There will surely be proposals like "custom formatters" that will simply not affect error monitoring tools. So we should alter our Stage 4 process to account for this.
3. @bmeurer had a good idea that perhaps we can merge those two categories into just a "debuggers" category (dropping the word "interactive"). This would give us some flexibility that only the constituents affected by a proposal have to implement it.
4. This also lead to a deeper conversation about the # of constituents required for stage 4. I think this last week has really shown us the breadth of source map users in the ecosystem. I've left it at 2 and 2 for now but would be happy to change it.
5. @sokra also pointed out that it might be nice to have some sort of criteria around an end to end implementation of a new feature. Proving that, for example, we can generate scopes with Babel/gen-mapping and consume those exact scopes with Chrome/Firefox.

[lforst]

As someone from the "Stack trace validators" group this seems fine because we are likely covered by the debuggers group as a more strict validator already 👍