Make always_redraw more user-friendly

Nobody has claimed this yet.

## Enhancement proposal

In my mind, `always_shift`, `always_rotate` are meant for users with little understanding of all these lambda and add_updater stuff. They just type always_shift(mobj) and the code does the rest.

```py
always_shift(my_square, LEFT, rate = 2)
always_rotate(my_line, rate = 2, about_point = RIGHT)
```
Pretty user-friendly, right? It's as simple as plain English: always_X applies a switch to my object that causes it to move.
Now let's take a look at `always_redraw`:

```py
my_circle = always_redraw(lambda : Circle().next_to(something))
```

This immediately raises so many questions from a non-experienced user. Why do I assign `mobject = switch`? This will result in an error, right? What is lambda?

Benjamin Hackl proposed creating a new function instead of modifying `always_redraw`, namely `always_become`. Another idea is `always_replace`, because this is what it does - teleport myobj by replacing it with a copy of target_mobj. The way I see it is:
```py
def always_replace(mobj, target_mobj):
"""adds an updater to mobj that replaces mobj with
a copy of target_mobj each frame"""
mobj.add_updater(lambda mobj: mobj.become(target_mobj))
```

```py
moving_circle = Circle().move_to(my_path)
always_replace(my_circle, moving_circle)
```

## Additional comments

Start by reading the existing always_redraw and always_shift entry points and compare their usage in the examples shown in the issue. Determine whether the desired change is a new always_become or always_replace API, or a revision to always_redraw, then define the expected user-facing behavior and tests before implementation.

Written by the indexing model from the issue text.