bluetooth/gst: Unify encoder and decoder pipeline setup
The encoding and decoding pipeline are essentially identical: both push data in via an appsrc, route it through a codec-specific (opaque) element, and finally pull data out of an appsink. The code already makes it impossible to have an encoding and decoding pipeline simultaneously set up in `gst_info`, and converting `bool for_encoding` to a tri-state (encode, decode, or both) would be messy; particularly when encoding and decoding could possibly differ in format. This change removes a swath of code and removes the possibility of misusing `enc_` or `dec_` in the wrong place (ie. after copying a bit of code and forgetting to rename one or two). When bidirectional codecs come online a second codec instance (`gst_info`) can simply be created and controlled independently. Part-of: <pulseaudio/pulseaudio!487>