Guidelines on what's reasonable to include in manim package + "contrib" package/folder/repo

## Enhancement proposal

I started learning manim and because I'm the kind of person who likes to generalise everything, I decided to make more-general mobjects for some of the shapes and objects that I've been making, e.g. I made a mouse cursor shape that someone else might be useful. But right now, there's not really any guidelines on what seems reasonable enough to put in the manim package itself.

From what it seems, anything generally mathematical and generalisable is free reign, and stuff like graphs, functions, number lines, etc. that are done properly definitely would make sense to include. However, if someone decides to make a star shape, would that be reasonable to include? What about a petersen graph?

I'm sure that these sorts of things are useful for folks to make and that they're probably examples of stuff people have already made, but there's really not a great example of a place to put them. We have `example_scenes` for entire scenes but it's not clear what kind of examples go here, how big they should be, etc. It's obviously useful to have entire projects, and maybe there should be a place to link repos of projects that people are willing to share, but sometimes smaller, self-contained bits for individual shapes or diagrams might be useful too, and if they're in a central place someone who reuses them could also modify them to be more general and help others out.

Basically, what I'm suggesting is like an "incubation area" for ideas of things that people have made, without any strict expectation of maintenance. Basically, the requirements would be:

1. Each bit is self-contained in a python module that works on the recent version of manim at time of submission, with that version documented in the file somewhere. (If there's a major update right after they submit it it's fine to not update it for the latest version.)
2. Depending on whether the code is for a mobject or a scene, we sort them into either a scenes or mobjects folder. Ideally over time a lot of the stuff would be moved from scenes to mobjects.
3. They're not expected to work in all cases, e.g. if you have some sort of shape and you set `edge_length` to `2 + 4j` or `-1`, don't expect it to work as you expect.
4. They should have documentation (one sentence is fine) of what the code is supposed to do, with one or two examples.
5. The author agrees to offer their code under the permissive license of manim (i.e. no attribution) and for people to modify the code as they wish.
6. Should follow basic-sense guidelines for the project (e.g. nothing profane, no copyrighted content, etc).

Folks are free to modify the code, generalise it, fix bugs, etc. with the caveat that every time a file is updated, it should work on the latest version of manim.

## Additional comments

Part of the reason why I suggest a separate repo for this is so that pull requests for the main project don't get bogged down by contributions to a "contrib" folder. Another potential benefit is that, after a while, we could potentially use some of the code that generates the documentation website to offer a version of the docs website for the contrib stuff, that would show off the scenes and objects that folks have made. Individual mobjects could be shown off with a `ShowCreation` animation.

One of the biggest benefits of this obviously would be the ability to take existing code and integrate it into manim if others find it useful enough. For example, if one person makes a relatively jank way of displaying a particular type of function, someone else might be able to take that code and clean it up a bit, and then maybe over time it could be included in the official manim package. Individual people who are looking to learn manim can also benefit from the files that people have made being in one place.

Note that there are other ways of doing this, and that we could simply have links to multiple repos where people store manim stuff, but I feel like adding stuff to a central location might encourage collaboration and maybe even people just adding stuff that they think is cool as a way of showing off manim and what it can do.

Start by reviewing the proposal's discussion of example_scenes, the possible contrib structure, and the documentation website code it mentions. The work is done when the project has an agreed location or repository, contribution guidelines, maintenance expectations, and documentation for how examples and reusable objects should be submitted.

Written by the indexing model from the issue text.