Limit on number of concurrent FCPs

Most people have lives outside of Rust and only have a limited amount of time each week to dedicate to reading RFCs and commenting. Even when someone does have plenty of time, they can still get burnt out focusing on just a few really lively RFCs. When a whole truckload of RFCs are shoved through FCP at the same time, people end up only being able to pay attention to some of them, while other RFCs slip by unnoticed. The current situation is borderline ridiculous:

Rust is not currently lacking in things to implement or stabilize (we have 277 open tracking issues!), so perhaps it might be wise to limit the number of RFCs that can be in FCP at a given time. We should instead strive to have a slow continuous stream of RFCs so there is always something to comment on, but not so much that people are inundated.

And no, having an "impl period" where you don't merge RFCs and instead focus on implementation is not a valid excuse for cramming as many RFCs into FCP in preparation for that "impl period".

No files, tests, or implementation entry points are identified in the issue. Start by reviewing the repository's RFC and FCP process and the existing discussion; done would require an agreed limit on concurrent FCPs and a clearly defined process change.