draw_ram_indicator() easier numbers to read, includes RAM just collected

[jdlcdl]

Description

The idea here was twofold:

• easier free RAM numbers to read (between 1 and 1023) usually 3 digits of precision with K or M to see the big picture,
• remember amount of free RAM before gc.collect() frees it so that we can see how much was recently collected... but this will not always be true if there is a habit of using gc.collect() within routines that are memory-costly.

Since there will be loops that absolutely require gc.collect(), perhaps we can make a habit of doing it like:

pre_collect = gc.mem_free()
gc.collect()
print("%s has collected %d bytes" % (__name__, gc.mem_free() - pre_collect))

...so that we can at least see how much memory had been used and that gc.collect() freed it for x times for this routine? Otherwise, a bad habit of collecting memory even when it's not necessary may become the norm?

Alternately, I wonder if we might never gc.collect() except where we are absolutely sure it's necessary... and then more generally use try/except "MemoryError", then do gc.collect() within the except block, and continuing on?

What is the purpose of this pull request?

Debugging RAM usage.

• [ ] Bug fix
• [ ] New Feature
• [ ] Documentation update
• [X] Other

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 94.21%. Comparing base (8166a9e) to head (51b13a2). Report is 2 commits behind head on develop.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## develop #452 +/- ## ======================================== Coverage 94.21% 94.21% ======================================== Files 59 59 Lines 7259 7259 ======================================== Hits 6839 6839 Misses 420 420 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[odudex]

Thank you Jean! Your indicator improvements will help answer these questions we all have.