Fixed lock-order reversal between sock lock and inp lock when setting
l2info on a socket.

The sock lock was being held by sosetopt() across the call to
ip_ctloutput(), which acquires the inp lock, now out-of-order.  This
tends to show up when the l2info is being set on a freshly accepted
socket while segments for that socket are being processed by
tcp_input() - when tcp_input() tries to acquire the receive sockbuf
lock while holding the inp lock, deadlock ensues, as the sock lock and
the receive sockbuf lock are currently one and the same.