Show core and contrib modules separately

Tagging for architectural review to see if this is someone we want to implement in core or leave for a contrib module like contrib.

Tagging for usability to see if this introduces any regression.

Moving to NW though as I'm not sure using a hardcoded list is the best approach. Would be something that would have to be kept up with potentially and not sure committers will be for that.

Did post in slack also.

Thanks for looking at it @smustgrave.

I agree that hardcoding the list is a less than ideal solution, but it was what I could make work, to create a rough sketch of my idea, and separate core and contrib modules.

I hope an experienced PHP coder can come up with a more elegant solution :)

And thanks for alerting developers on Slack. I hope that instead of possibly discussing it there, it would be great if it was discussed here. Slack, dare I say, feels a little "behind closed doors", and we have this great forum, where everyone can follow along. Also those not on Slack.

This is a complex topic and screen :) Before considering the proposed solution, it would be good to provide more concrete info on how the current sorting and grouping is causing problems. "Can be confusing" is a bit thin in that regard :)

I'm sure the current state can be improved, but not so confident that this proposal points towards a more managable situation:
- Already the core categories are a mix of "core-core" and additional topic/feature specific groupings (fields, multilingual, migrate...)
- Not all contributed modules add functionality on the same scale and scope. Commers or Groups introduce whole new concepts and would merit their own section, but would a contrib module that provides a new field type really add it's own section at the bottom instead of adding itself in the existing Fields section?
- Not sure how adding the version number helps here?

Main point is that it would be good to get a better grasp on the usability problems here before exploring possible solutions.