Refactor CEL channel events on top of Stasis-Core

This uses the channel state change events from Stasis-Core to determine
when channel-related CEL events should be raised. Those refactored in
this patch are:
* AST_CEL_CHANNEL_START
* AST_CEL_ANSWER
* AST_CEL_APP_START
* AST_CEL_APP_END
* AST_CEL_HANGUP
* AST_CEL_CHANNEL_END

Retirement of Linked IDs is also refactored.

CEL configuration has been refactored to use the config framework.

Note: Some HANGUP events are not generated correctly because the bridge
layer does not propagate hangupcause/hangupsource information yet.

Review: https://reviewboard.asterisk.org/r/2544/
(closes issue ASTERISK-21563)


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@391622 f38db490-d61c-443f-a65b-d21fe96a405b
Refactor CEL bridge events on top of Stasis-Core

This pulls bridge-related CEL event triggers out of the code in which
they were residing and pulls them into cel.c where they are now
triggered by changes in bridge snapshots. To get access to the
Stasis-Core parking topic in cel.c, the Stasis-Core portions of parking
init have been pulled into core Asterisk init.

This also adds a new CEL event (AST_CEL_BRIDGE_TO_CONF) that indicates
a two-party bridge has transitioned to a multi-party conference. The
reverse cannot occur in CEL terms even though it may occur in actuality
and two party bridges which receive a AST_CEL_BRIDGE_TO_CONF will be
treated as multi-party conferences for the duration of the bridge.

Review: https://reviewboard.asterisk.org/r/2563/
(closes issue ASTERISK-21564)


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@391643 f38db490-d61c-443f-a65b-d21fe96a405b