net: shell: Fix TCP connect behavior

Fix two issues with net tcp command:

* The `net tcp` commands are still based on net_context API. For TCP,
  the API caller (net shell) should add one extra reference to the
  allocated net context, to prevent premature context release in case of
  connection teardown. Currently that was not the case, and the context
  was released too early, resulting in missing final ACK from the Zephyr
  side on connection close.

* The net context API should not be called from the registered connect
  callback, as this creates a temporary deadlock situation. The
  net_context_connect() function blocks until the connection is
  established, or an error or timeout occurs. For that time the
  net_context mutex is being locked. In case of connection error (for
  example after receiving RST packet) the connect callback is called,
  indicating an error. If we try to call net_context API from within, a
  deadlock situation takes place, as the context mutex is still locked
  by the net_context_connect() (called from the shell thread). This
  blocks the further execution of the TCP stack and can result in an
  unexpected behavior (like for example retransmitting the SYN packet,
  which takes place from yet another thread, TCP work queue).
  Fix this, by releasing the net context not from the callback directly,
  but based on the return value from net_context_connect().

Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>