t values issue that causes the animations to not be finished entirely.

@huguesdevimeux is already working on this.

Since Jul 24, 2020.

• #698 by @leotrs — closed without merging

y values are generated with those lines : (progress_through_animations, l883, scene.py).
```python
for t in self.get_animation_time_progression(animations):
dt = t - last_t
last_t = t
for animation in animations:
animation.update_mobjects(dt)
alpha = t / animation.run_time
animation.interpolate(alpha)
self.update_mobjects(dt)
self.update_frame(moving_mobjects, static_image)
self.add_frames(self.get_frame())
```
`get_animation_time_progression` returns a ProgressBarDisplay object, from the library tdqm that we use to display the progress bar.

When doing -s, skip_animations is enabled to t value is set to 1.0 (no intermediary values as we just need the last frame).

When running normally, eg with 15 fps, there are logically 15 t values, that are :

```
0.0
0.06666666666666667
0.13333333333333333
0.2
0.26666666666666666
0.3333333333333333
0.4
0.4666666666666667
0.5333333333333333
0.6
0.6666666666666666
0.7333333333333333
0.8
0.8666666666666667
0.9333333333333333
```
As you may see, 1 is never reached. In other terms, the animations is stopped at 93%). Not that 1.0 change depending on the rn_time : if the run_time was let's say 3, last t value would be 2.93.

We can see this issue with a single pixel that should be here :

To give an idea of a fix, I will use the words of @leotrs :

> I've never used tqdm myself so my question is: is it orthodox/expected/good practice to determine the course of a program by querying the progress bar itself? I'm not sure how this works at all.
>
> It'd be much more reasonable I think for manim to determine its own course of action and then tell the progress bar to reflect that, instead of the other way around