Experimental Progress Tracker

# Experimental Progress Tracking
Tracker issue for rewriting the core of Manim

## Currently working on:
If you're interested in helping out, try running `pytest`, choosing a test that fails, and fix the test!

## Before merging into Main
Essentially, what needs to be done in #3112

- [X] Restructure the render loop to use `Manager` (#3785)
- [x] Merge `main` into `experimental` (#3815)
- [x] Functioning `FileWriter` (#3821)
- [x] Sections (#3883)
- [ ] Skipping to animation number
- [ ] Fix all `Animation`s
- [ ] `Scene` subclasses
- [x] `ThreeDScene` (#4059)
- [x] Animation of `Camera` (#4059)
- [ ] Clean up the code
- [ ] Instanced Rendering (#3816)
- [ ] `ImageMobject`
- [ ] `PMobject` (is this even used?)
- [ ] Get all tests working

### Nice to have
The following would be nice to have, but could also be implemented in follow-up PRs to reduce the diff.
- [x] Rewrite VMobject to be renderer agnostic
- [ ] Double pass rendering to decouple `Scene` and `Manager`
- [ ] Audio support

## Follow-Ups
- [ ] Caching
- [ ] Plugin Hooks

## Timeline Goals
- `v0.20.0`: Experimental should have most tests passing
- `v0.21.0`: Experimental should be released, and the follow-ups should be in the process of being implemented.

# But... Why?
## Motivation
The current Manim codebase is very entangled.

To give you a sense of what I mean, let's look at an example.
The renderer has access to a file writer. The Scene has access to the renderer, and as such indirectly to the file writer as well. But the renderer also has a reference to the scene. To make matters worse, at some points in time animations also have references to the scene (sometimes), and much more. This is an attempt to clean that up by introducing a `Manager` class whose sole job is to orchestrate communication between the `Scene`, `FileWriter`, and a `Renderer`.

Additionally, the current implementation of renderers (OpenGL mainly, but Cairo as well) in Manim is unmaintainable. The `OpenGLMobject` contains shaders inside itself! This means in the future if we ever want to allow more types of renderers (e.g. `Metal` for MacBooks), we'd have to create a _third_ base Mobject, and a new `Camera`, which is just stupid. Instead, `*Mobject`s should be renderer independent, and all the renderer specific stuff should be inside a class implementing the `RendererProtocol`.

## New Structure
Here you can see every class has its own responsibilities. The `Camera` is responsible for the `FOV`, the `Scene` for orchestrating animations, `Mobject`s have no dependency with the renderer, and the `Renderer` only cares about a `SceneState`, not the actual `Scene`.