Remove the IMSG_NEIGHBOR_CHANGE message

Unlike OSPF, LDP has no concept of intermediate states. A session is
either operational or not operational as far as the label distribution
engine (lde) is concerned. In this case, the IMSG_NEIGHBOR_UP and
IMSG_NEIGHBOR_DOWN messages are enough.
Minor adjustments in the startup of the lde and ldpe processes

The 'ldpd_process' variable should be set as soon as possible in the
initialization of each process. In that way if something goes wrong in
the initialization we will know in which process the problem happened.
Minor adjustments in the initialization FSM

* Remove the unused NBR_EVT_DOWN event;

* Print the FSM transitions before performing the appropriate actions. In
this way nested calls to nbr_fsm() won't print the state transitions in
reverse order;

* When acting in the active role of the initialization process, transition
from NBA_STA_PRESENT to NBR_STA_INITIAL before going to NBR_STA_OPENSENT
(cosmetic);

* Call session_shutdown() on nbr_ktimeout() to remove duplicated code;

* Notify the lde process when a neighbor is deleted (discovery timeout);

* Fix a few memory leaks on nbr_del();
Properly implement the exponential backoff timer on session initialization

According with the section 2.5.3 of RFC 5036, an LSR must throttle its
session setup retry attempts with an exponential backoff in situations
where Initialization messages are being NAK'd (because of disagreements
on session parameters). It doesn't mention using this procedure for TCP
connection failures. With that said, start the inactive delay timer only
after receiving an appropriate notification message.

When acting in the active role, throttle the session setup retry attempts
by not connecting to the remote peer. When acting in the passive role,
throttle the session setup retry attempts by delaying the processing of
the received initialization message.
Implement support for adjacencies and targeted hellos
Cleanup ctl commands and remove unused variables inherited from ospfd
Be more compliant with the specification in the initialization process

RFC 5036 says:
   "After the connection is established, if LSR1 is playing the active
   role, it initiates negotiation of session parameters by sending an
   Initialization message to LSR2.  If LSR1 is passive, it waits for
   LSR2 to initiate the parameter negotiation.

   In general when there are multiple links between LSR1 and LSR2 and
   multiple label spaces to be advertised by each, the passive LSR
   cannot know which label space to advertise over a newly established
   TCP connection until it receives the LDP Initialization message on
   the connection.  The Initialization message carries both the LDP
   Identifier for the sender's (active LSR's) label space and the LDP
   Identifier for the receiver's (passive LSR's) label space.

   By waiting for the Initialization message from its peer, the passive
   LSR can match the label space to be advertised by the peer (as
   determined from the LDP Identifier in the PDU header for the
   Initialization message) with a Hello adjacency previously created
   when Hellos were exchanged."

With that said, we should always accept TCP connection requests
and identify to which neighbor it belongs only _after_ receiving an
Initialization message containing the information we need. Before an
Initialization message is received, the TCP connection shouldn't be
associated with any neighbor/adjacency.

The question now is: why going through all this trouble if we don't
support per-interface labelspaces? The anwer is in the next commit.
Speed-up the session establishment process

* Send an extra Hello message before attempting to connect to a remote
peer to guarantee that it formed an adjacency with us as well;

* Don't wait for the first timeout to send the first Hello message. If
we are playing the passive role, the remote peer will immediately
establish a TCP connection with us and then send an Initialization
message. The problem is that we may have not formed an adjancency with
the remote peer yet. In this case, we would close the TCP connection
and then send a notification message (No Hello), which would trigger the
backoff exponential timer in the remote peer. In practice this problem
doesn't occurs because most implementations use the first optimization
mentioned above.

Note: the Cisco IOS implementation only sends an extra hello message
_after_ the TCP connection with the passive peer is established and
_before_ sending the Initialization message. Without the previous
commit, we wouldn't receive the extra Hello message from IOS, which
would considerably slow down the session establishment process.