[Ovmsdev] Update WolfSSH/SSL

[Stephen Casner]

After a pause of three years, I have finally gotten around to updating
wolfssh and wolfssl to the current stable releases, 1.4.5 and 4.6.0
respectively.  This includes the code to support SCP that I wrote and
contributed back to them and was integrated into wolfssh 1.3.0.  There
were some API tweaks that I needed to work through, but the source
files are now unmodified except for wolfcrypt/settings.h where I ran
into a compilation conflict on the XREALLOC macro.  As before, I need
to supply my own malloc, free and realloc functions so we can control
PSRAM usage and so we can emit a log message if memory allocation
fails.

For starters, this update removes the restriction to use cipher
aes128-cbc.  In addition, the WolfSSL code now includes integration
with the hardware crypto acceleration capabilities of the ESP32.  I'm
not sure how much that will affect performance as we see it because I
think the biggest performance factor is how we need to use the APIs
given our task structure.  The public key handshake for initial
connection may be faster.

I added the new code on a branch named update-wolfssh by copying in
the source files as I did when creating the wolfssh and wolfssl
components initially.  I'm running the new code on OVMS in my car and
have given it basic testing by connecting with the ssh client and
transferring files with scp.  I invite anyone else who is interested
to test as well or to comment if there are any concerns about merging
to the master branch.  There are some memory considerations.

I've added the complete wolfssl source tree even though we only use
the wolfcrypt subset of wolfssl.  The update added a bunch of files
and increased the required disk space from 18M to 43M.  Similarly,
wolfssh added code for scp, sftp, ssh agent server code and also ssh
clients that we are not using; that increased disk space from 2.0M to
2.6M.  I added our scp code before they implemented theirs and I have
not examined their scp and sftp code to see if there would be any
advantage in trying to adapt it to fit our non-blocking architecture.

I had to increase the size of the NetMan stack from 8K to 10K to avoid
stack overflow.  With current master code the max used on my OVMS was
5616 whereas after the update it is 9700.

With the current master code, the amount of memory added by NetMan
when an ssh connection was established was 2557 D/IRAM and 6108 SPIRAM
for 8665 total.  With the update it was 1240 D/IRAM and 8768 SPIRAM
for 10008 total.

                                                        -- Steve