Description: Find a way to identify when a containers ceased it's existance

Steps to Reproduce:

1. Compose some containers
2. Run ds
3. Compose down those containers

Expected Behavior: No containers left on the screen.

Actual Behavior: Some containers are deleted but the remainder one's, the ones that never got any new lines after never receive the "signal" to print. The docker stats never tells you when something is destroyed, it just disappears witch is hard to identify on a stream, when it's lag or common delay & when it really should be excluded.

Screenshots/Logs: Nah.

Environment:

• Rust version: 1.73.0-nightly
• Operating System: macOS
• CLI version (if applicable): Not yet.

Description: In the current implementation ds uses simply a println! to update the terminal charts, but this causes a horrible experience when you scroll up, so you stop "following" the new updates, also it completely overwrites anything on your terminal history flooding with new lines and old charts.

Use Case: Yes...

Proposed Solution: Reading more about it I found about Cursor Movement, those enable you to keep "reusing" and rewriting lines since you can now keep track of'em using the ANSI escape sequences \033[s and \033[u to save and restore the cursor position, this creates a issue, you'll rewrite the chars used, but if the past line had more content than the new one the rest will be present, for that also exists a ANSI escape sequence \033[K witch cleans to the end of the actual line. So with something like:

# Save the cursor position
printf "\033[s"

# Clean and print the argument
cap() { printf "\033[K$1\n"; }

for i in {1..5}; do
  # Restore the cursor position
  printf "\033[u"

  cap "foo ${i}"
  cap "bar ${i}"

  sleep 0.05
done

# Restore the cursor position
printf "\033[u"

cap "Heyy"
cap "Yoo"

We can have a set of fixed lines being updated witch solves, or at least I think will solve the issues in the description.

Additional Context: Nope.

This closes #5 for now, after a series of tests I described on the issue this seems like a reasonable and simple enough solution to break in the final product.