kernel-interface: Change reqid if seq. nos. are supported and narrowing occurred

kernel-interface: Change reqid if seq. nos. are supported and narrowing occurred

With the sequence numbers we don't have to maintain the reqid to delete
the temporary state.

One exception is with labels.  There we currently only install trap
policies with the generic label.  SAs created from those don't have
policies installed, so we have to reuse the reqid of the trap even if
narrowing occurs.

And as before, we reuse the reqid without checking traffic selectors if
sequence numbers are not supported.

Note that if a CHILD_SA is manually initiated (i.e. has no sequence
number assigned) right before an acquire is triggered, there are several
possible outcomes depending on whether narrowing occurs.  If there is no
narrowing, the same reqid is assigned and the kernel will remove the
temporary SA when the SA is installed (no seq => reqid match).
Afterwards, the queued duplicate CHILD_SA is destroyed and the acquire
state in the trap manager gets removed.  If there is narrowing, a new
reqid is allocated, so the installation of the SA will not remove the
temporary state.  However, due to the narrowing, the duplicate check
fails and when the duplicate is installed (with sequence number), the
temporary state is deleted (as is the state in the trap manager).