channel: is_local_eof|closed getters

Given an invocation to 'ssh_channel_close', upon SSH_AGAIN, there
is currently no way to know whether the SSH_AGAIN means that EOF
has been totally sent and CLOSE message bytes have been enqueued,
or whether sending and flushing EOF needs to be retried, and CLOSE
message bytes are yet to be queued.

Expose getters for 'local_eof' and the new field 'local_closed'.
Until the latter is set, it is not the case the CLOSE message
bytes have been enqueued to the outgoing session socket.

Motivation: when unable to distinguish the above ssh_channel_close
cases, clients either have to resort to missing a channel close, or
possibly sending more than one CLOSE message for a given channel.
Both of those options are bad for the case of session multiplexing
(for example, OpenSSH might indefinitely hang if it never sees a
corresponding CLOSE response for a closed channel; likewise, it
may abruptly disconnect if it receives a duplicate CLOSE or a
CLOSE for an unknown channel).