Move AudioDecoder and related stuff to the api/ directory

webrtc/api/DEPS

 include_rules = [
   "+third_party/libyuv",
   "+webrtc/base",
   "+webrtc/common_video",
   "+webrtc/media",
   "+webrtc/p2p",
   "+webrtc/pc",
 ]
 
 specific_include_rules = {
   "peerconnection_jni\.cc": [
     "+webrtc/voice_engine",
   ],
 
-  # TODO(kwiberg): Remove this exception when audio_decoder_factory.h
-  # has moved to api/.
-  "peerconnectioninterface\.h": [
-    "+webrtc/modules/audio_coding/codecs/audio_decoder_factory.h",
+  # We allow .cc files in webrtc/api/ to #include a bunch of stuff

[kjellander_webrtc, 2017/02/01 14:54:50]

Which are the cases for this? It sounds like those .cc files should live in
webrtc/modules/audio_coding

[kwiberg-webrtc, 2017/02/01 20:15:02]

Files in api/ must be allowed to include files outside api/---otherwise, we
might as well delete all the non-api/ files since they're dead code.

Letting .h files in api/ include non-api/ stuff is too risky, though (see the
comment added here), so restricting that to .cc files in api/ makes sense I
think.

[ossu, 2017/02/06 12:54:16]

Yeah, if api/ is to be the one and only external access point to webrtc,
something like this is definitely necessary. The other option would be to have
interfaces etc. in api/, but have implementations accessed outside of api/. E.g.
api:audio_decoder_factory_api gives you the interfaces you need to talk about
audio decoder factories, but to get our implementation when you need to
instantiate such a factory, you'd depend on
audio_coding:builtin_audio_decoder_factory, for example. Though I expect that
option has already been discussed and rejected during the "Slim and modular"
discussions. 

[kjellander_webrtc, 2017/02/10 07:58:48]

Thanks for explaining. Let's do this.

+  # that's off-limits for the .h files. That's because .h files leak
+  # their #includes to whoever's #including them, but .cc files do not
+  # since no one #includes them.
+  ".*\.cc": [
+    "+webrtc/modules/audio_coding",
   ],
 }