There is currently no distinction between the "peer busy" and "we
replied busy after timeout" states, since both end in the BUSY state.
Add a new PEER_BUSY state allowing such a distinction:
* PEER_BUSY is set when peer replied busy
* BUSY is set when we replied busy to an incoming call
Bump daemon API number to major 7.0.0 since this is breaking the
current API. In fact, these changes should not break anything in
any well implemented client because unknown states should be properly
handled, but better check.
Reviewed-by: Sebastien Blin <firstname.lastname@example.org>