A better data structure for `VMobject`s

## Enhancement proposal
Currently, Manim stores the point data for `VMobjects` as a flat list of points. This is not representative at all of how `VMobjects` are actually structured, i.e. as composite bezier curves. In fact, every four points (three for OpenGL) form the points defining a cubic/bezier curve, yet they are currently not explicitly grouped together. Furthermore, the data of which points form what paths is not stored, and Manim instead spends a significant amount of time every frame checking whether for each pair of consecutive bezier curves, their end and start points are close enough to be considered part of the same path. This is of course extremely inefficient. I'm not exactly sure on how to resolve these problems, but a good data structure should have the following properties:

- Explicitly groups the data for each bezier curve together
- Explicitly groups the data for each subpath together
- Does not cause a significant performance loss when pointwise functions (functions acting on each point of the VMobject) are applied (perhaps grouping the points might cause overhead in this respect)
- Works with current animations (if paths are explicitly grouped, how do we implement a transformation of a VMobject to another VMobject with a different amount of paths?)
- Easily extendible to support different path components (like arcs and lines)

## Additional comments

Start by tracing VMobject point storage and the per-frame check that determines whether consecutive Bézier curves belong to the same path, as described in the issue. No files or tests are named, so identify the relevant implementation and animation behavior before proposing a structure. Done means curve and subpath grouping, pointwise-function performance, animation compatibility, and future support for other path components are addressed.

Written by the indexing model from the issue text.