Update README.

Update roadmap section with note about  plans are for the current (FIRST!) release.

Delete comments about OpenSSL bloat.  That referred to a bunch of stuff that was being loaded in by opensslwrapper.  We still do have some cleanup to do here.  In particular, we'd like to be able to get OpenSSL to work for the 25519 stuff, and get rid of our reference code.  Another potential project is to use libsodium for everything, which may be leaner and faster -- however, that might require us to switch to AES-GSM.  That would be a fine idea, but it would introduce a wire incompatibility.  (We might end up doing this for the first release, to avoid having to deal with compatibilty issues.)

Also delete comments about STL container bloat.  I have converted almost all of the ordered maps to hashmaps, which do not do seperate heap allocations per item.  There are 2 or 3 remaining std::maps in the reliability layer, but those are constrained to a max size (to protect against a malicious peer), so I don't think this is high priority.  It would be good to fix this to limit the use of the heap to an absolute minimum, but for now tehre are more important issues.

README.md

@@ -277,7 +277,11 @@ This extension comes in handy if you're editing the Meson build files.
 VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=asabil.meson
 
 ## Roadmap
-Here are some areas we're actively working on improving.
+the current focus is to get a stable release that matches the first release of
+this interface in the public Steamworks SDK.
+
+After that, here are some large features that we expect to add to a future
+release:
 
 ### Bandwidth estimation
 An earlier version of this code implemented TCP-friendly rate control (RFC
@@ -301,21 +305,6 @@ Steamworks code already has those concepts, it should be pretty easy to add
 support for this.  You'd still be responsible for running the STUN/TURN servers
 and doing the rendezvous/signalling, but the code could use them.
 
-### OpenSSL bloat
-Our use of OpenSSL is extremely limited; basically just AES encryption.  We use
-Ed25519 keys for signatures and key exchange and we do not support X.509
-certificates.  However, because the code is going through a wrapper layer that
-is part of Steam, we are linking in much more code than strictly necessary.
-And each time we encrypt and decrypt a packet, this wrapper layer is doing some
-work which could be avoided.
-
-A recent refactor made it possible to replace OpenSSL with libsodium, and we
-should be able to configure that to have much less waste.
-
-### Use of STL causing more dynamic memory allocations than necessary
-There are a few STL maps and such that could be significantly optimized by the
-use of custom data structures or allocators.
-
 ### Non-connection-oriented interface
 The Steam version has ISteamMessages, which is a UDP-like interface.  Messages
 are addressed by peer identity, not connection handle.  (Both reliable and