Update audio api to use v2 stable device ID

extensions/common/api/audio.idl

Index: extensions/common/api/audio.idl
diff --git a/extensions/common/api/audio.idl b/extensions/common/api/audio.idl
index 36a1124bd3b66b81339248e984c368cb6b9e5885..f958b4376c6195f368148d5669f3db85e09e8b5d 100644
--- a/extensions/common/api/audio.idl
+++ b/extensions/common/api/audio.idl
@@ -52,7 +52,12 @@ namespace audio {
     boolean isMuted;
     // The sound level of the device, volume for output, gain for input.
     long level;
-    // The stable/persisted device id string when available.
+    // The stable/persisted device id string.
+    DOMString stableId;

[Devlin, 2016/12/20 18:15:45]

This is kind of a shame - we now have 3 different ids on this single object.  Is
there no way we can do this opaquely to the developer?

[tbarzic, 2016/12/20 18:51:20]

I guess we could, but at cost of the app losing information previously saved in
their storage (which was the goal of introducing stableDeviceId in the first
place).

Note that this API is still in dev, and currently used by a single app. I plan
to expose deprecated stableDeviceId only to the current whitelist, and
eventually remove it altogether.

[Devlin, 2016/12/20 19:36:17]

That makes it better.  If that's the case, can we just reach out to that app and
say "by the way, this is gone"?  Or do we really need this transition period?

[tbarzic, 2016/12/20 19:53:56]

We could, but imho it would be better to provide the app a chance to update
their stored mapping from stableDeviceId to device properties.

Adding +mnilsson to check if we could get away with just replacing stable IDs
(without providing a transitional period where both deprecated and new stable ID
are exposed).

+
+    // Deprecated version of stable audio device ID. Available for backward
+    // compatibility - usages should be migrated to |stableId|.
+    [deprecated = "Use |stableId|."]
     DOMString? stableDeviceId;
   };