Move header to payload front

I moved the header to the front of the payload buffer, like so:
```
+---------------+-------------------+
|   symbol id   |    symbol data    |
+---------------+-------------------+
```
I did so in the interest of making the API more simple.

This could potentially cause performance issues, but I haven't been able to get any definitive results by running  the benchmarks though.
I thought a bit more about it and here is the tentative conclusion:

Different applications will define different header formats in some cases field are fixed size and in some cases fields a variable length (typically implemented using a length field and a data field). 

In some cases a fixed size field is appropriate, i.e. if the information encoded never changes. But, in some cases when the length of information encoded varies, potentially significantly, and it can be more optimal to encode the information in a variable length field.  

An example: In network coding this is also the case. I.e. when sending a systematic symbol it can be very wasteful to send the entire encoding vector. 

To support both use-cases in the API we do the following, lets say we want to implement functionality to write some information called flux. We would implement a 4-tuple 

```
uint32_t max_flux_size() const;
uint32_t flux_size() const;
uint32_t write_flux(uint8_t*);
uint32_t read_flux(const uint8_t*);
```

So the ``max_flux_size() const`` tells us that no matter what the flux field will never grow larger (given the ``max_symbols()`` and ``max_symbol_size()``).

The ``max_xyz()`` functions allow us to propagate to the user that if he/she allocates a buffer of the size ``max_payload_size()`` it can be used for any valid setting of symbols and symbol size (no re-allocations will ever be needed).

Similarly the ``flux_size() const`` tells us that no matter what the flux field will never grow larger for a specific encoder or decoder (given the *chosen* number of  *symbols* and *symbol size*).

This also means that ``write_flux(uint8_t*)`` and ``read_flux(const uint8_t*)`` will never exceed the ``flux_size()`` number of bytes. 

These two functions will return the actual number of bytes written and read respectively. 

For variable length fields one can implement something like this:

´´´
uint32_t capacitor_layer::write(uint8_t *payload)
{
    uint8_t* payload_size = payload;
    uint8_t* payload_flux = payload + SuperCoder::flux_size();
   
   uint32_t written = SuperCoder::write_flux(payload_flux);
   sak::big_endian<uint32_t>::write(payload_size, written);
   
   return SuperCoder::write(payload_flux + written) + written + SuperCoder::flux_size();
}
```

Ok don't have time to write more I think I will try to write something more.. I'm not finished thinking about it :)