ASoC: Implement mux control sharing

Control sharing is enabled when two widgets include pointers to the
same kcontrol_new in their definition. Specifically:

static const struct snd_kcontrol_new adcinput_mux =
	SOC_DAPM_ENUM("ADC Input", adcinput_enum);

static const struct snd_soc_dapm_widget wm8903_dapm_widgets[] = {
  SND_SOC_DAPM_MUX("Left ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux),
  SND_SOC_DAPM_MUX("Right ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux),
};

This is useful when a single register bit or field affects multiple
muxes at once. The common case is to have separate control bits or
fields for each mux (channel). An alternative way of looking at this
is that the mux is a stereo (or even n-channel) mux, rather than
independant mono muxes.

Without this change, a separate kcontrol will be created for each
DAPM_MUX. This has the following disadvantages:

* Confuses the user/programmer with redundant controls that don't
  map to separate hardware.

* When one of the controls is changed, ASoC fails to update the DAPM
  logic for paths solely affected by the other controls impacted by
  the same register bits. This causes some paths not to be correctly
  powered up or down. Prior to this change, to work around this, the
  user or programmer had to manually toggle all duplicate controls away
  from the intended setting, and then back to it.

Control sharing implies that the control is named based on the
kcontrol_new itself, not any of the widgets that are affected by it.

Control sharing is implemented by: When creating kcontrols, if a
kcontrol does not yet exist for a particular kcontrol_new, then a new
kcontrol is created with a list of widgets containing just a single
entry. This is the normal case. However, if a kcontrol does already
exists for the given kcontrol_new, the current widget is simply added
to that kcontrol's list of affected widgets.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>