We should bring community plugins into the docs

In #1535 (closed), @sedubois writes:

• people can create their own plugins and share them on the list of plugins wiki page, but that information tends to be outdated or not verified and so the quality information gets diluted;
• external plugins might not be as stable as Administrate itself, because people are basically on their own and e.g. cannot ask for their PRs to be reviewed by other Administrate users (and the wiki page itself is not subject to a review process), and conversely the maintainer him/herself might not be available any more (as my example above shows);
• various users (such as myself) might have functional custom administrate fields in their own private systems but have no clue how to turn that into a gem (although I'm not a good example because I could just have forked the outdated one; but then what should I put on the wiki page? Keep the outdated one, replace with my own, keep both?);
• even if one finds an external plugin that is functional, it does not benefit from a clear API documentation like the "official" API documentation;
• the documentation of these external plugins is fragmented (not available from the same central place);
• we might also end up in situations where an external plugin already addresses a need, but due to lack of visibility then we partially try to address the need internally (as in this PR), which defeats a bit the purpose of supporting external plugins.

I don't know what is the solution. Maybe the documentation system could integrate external plugins as well...

The intention of the wiki page was to reduce friction for people adding their plugins, but in practice that's just split the source of information.

I now think it'd be better to have a specific plugin listing page in the docs, with a section for Community Plugins plus an invitation for people to add theirs. This should add a bit of feedback too, which hopefully answers the other points.