add more functions to audio_stream internals

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

All stream parameters are now available as a single
structure

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

As no internals of audio_stream nor comp_buffer should be
accessible directly, move all calls to buffer_fmt to API
In addition, to let sink/source interface working,
move the parameter to audio_stream structure

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

this is a definition of API to source of audio data

THE SOURCE is any component in the system that have data
stored somehow and can give the data outside at request.
The source API does not define who and how has produced
the data
  The user - a module - sees this as a producer that
             PROVIDES data for processing
  The IMPLEMENTATION - audio_stream, DP Queue - sees
             this API as a destination it must send data to

Examples of components that should expose source API:
  - DMIC. Data are coming from the outside world,
          stores in tmp buffer and can be presented
	  to the rest of the system using source_api
  - a memory ring buffer
	Data are coming from other module
        (usually using sink_api, but it does not matter in fact)

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

this is a definition of API to sink of audio data

THE SINK is any component that can store data somehow
and provide a buffer to be filled with data at request.
The sink API does not define how the data will be processed/used

 The user - a module - sees this API as a destination
            it must send data to
 The IMPLEMENTATION - audio_stream, DP Queue -
            sees this as a producer that PROVIDES data for processing

Examples of components that should expose SINK api
 - /dev/null
     all the data stored in sink buffer are just simply discarded
 - I2S sender
     Data stored in sink buffer will be sent to the external world
 - a memory ring buffer
     data stored in the buffer will be sent to another module
     (usually using source API, but it does not matter in fact).

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

There are many operations on sink/source that may be put into a
common library. This is the place for it.

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

Make audio_stream capable of using pipeline2.0
sink and source API
This change makes integration of sink/src api
possible in incremental way

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

Target is to make all modules use sink/source API as
data source and destination.
However, current implementation of module adapter
allows 2 other completely different interfaces to be used:

"simple_copy"
  modules receive output_stream_buffer and
  input_stream_buffer table. void * data pointers
  from both structures point to audio_stream
  other fields in the structures are in fact not needed
  but are used

"! simple_copy"
  modules receive output_stream_buffer and
  input_stream_buffer table. void * data pointers
  from both structures point to raw linear data

to make transition smooth and easy, both
legacy ways have been kept, just to make the code
more clear - put at separate module API calls,

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

Module prepare is an operation that needs to set up sink
and source according to needs.
Therefore it must have access to sink/source handlers
This commit adds handlers to API. In case the module uses
legacy audio stream sink/source pointers will be NULLs
and number of sinks/sources will be zero

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>

This is a porting of SRC module to use sink/src API
To have src fully ported there's a need to get 100%
independent of audio_stream and buffer.c
This step is necessary because other implementations of
sink/src, like DP Queue, may not be based on buffer
implementation

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>