wct4xxp: Ensure all spans are configured by default.

Not configuring all the spans on an octal card can result in some of the
spans not working in clear channel modes.

Now ensure that all spans receive a default configuration regardless how
they are configured from user space.

Internal-Issue-ID: DAHLIN-289
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10728 a0bf4364-ded3-4de4-8d8a-66a801d63aff
wct4xxp: Companding on VPM needs to be changed when switching linemodes.

If a user switches linemode with sysfs, the VPM would never switch the
companding mode to alaw, and the result would be extreme static on all channels
of the span when the VPM is enabeld.

Now if the deflaw of the span has changed when an echocan is created, the
companding mode of the VPM channel is changed.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>

Conflicts:
	drivers/dahdi/wct4xxp/base.c
wctdm24xxp: Fix FXO failure to detect battery CO disconnects.

In 2.6.2 I introduced an error in (41639330a "wctdm24xxp: Eliminate chance for
channel to be stuck in RED alarm.") which would get an FXO stuck in detecting an
ONHOOK event from the remote side.  An FXO port could go into the
BATTERY_DEBOUNCING_LOST_ALARM state and then back to the BATTERY_PRESENT state
without sending the dahdi_hooksig up to Asterisk.  Therefore, Asterisk would
never detect the state changes needed for a remote side disconnect.

This change adds two more states, BATTERY_DEBOUNCING_PRESENT_FROM_LOST_ALARM and
BATTERY_DEBOUNCING_LOST_FROM_PRESENT_ALARM so that the state machine does not
miss any needed transitions when going back to BATTERY_PRESENT or BATTERY_LOST
regardless of why the debounce was started.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
(cherry picked from commit 244f621eb1c315725056635903e8a0180ebd0568)