This is more or less a complete re-organization of the code.
* Use the actual byte size of the .bin file as the flash size,
as the algorithm for packing sections into the flash is complicated
* Match each section to a data region & find the high water mark in the
region
* Report on all the RAM regions, separately
Note that elftools is a requirement of esp-idf and so does not need to
be listed in our requirements.txt.
This detects an overflowed flash partition, such as
```
1452105 bytes used, -10313 bytes free in flash firmware space out of 1441792 bytes (1408.0kB).
444428 bytes used, 1652724 bytes free in ram for stack and heap out of 2097152 bytes (2048.0kB).
```
on a metro esp32-s2 built with debugging.
From the change:
// xtensa has more registers than an instruction can address. The 16 that
// can be addressed are called the "window". When a function is called or
// returns the window rotates. This allows for more efficient function calls
// because ram doesn't need to be used. It's only used if the window wraps
// around onto itself. At that point values are "spilled" to empty spots in
// the stack that were set aside. When the window rotates back around (on
// function return), the values are restored into the register from ram.
// So, in order to read the values in the stack scan we must make sure all
// of the register values we care about have been spilled to RAM. Luckily,
// there is a HAL call to do it. There is a bit of a race condition here
// because the register value could change after it's been restored but that
// is unlikely to happen with a heap pointer while we do a GC.
Fixes#2907
Jeff Epler
microDev
Scott Shawcroft