Avoid 'force' and 'bitwise' macro clashes

These macro definitions may cause conflicts if
libtrading is used as a part of a bigger project.

For example 'bitwise' macro causes conflicts with
boost's bitwise definition.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@iki.fi>
BUG fix: buffer_peek_le16()

There are two problems with current buffer_peek_le16()
implementation:

1) It must return le16 but not u8 as follows from function's name
2) Because buffer->data is a signed char array, current implementaion
is buggy due to integer promotion.

Consider an example:
self->data[self->start] = -1
self->data[self->start + 1] = 0

The expected result is 255 but current version
returns 65535 because of the integer promotion.

* self->data[self->start] is promoted to signed integer
(0xFFFFFFFF in our case)
* self->data[self->start + 1] is promoted to signed integer
(0x00000000 in our case)
* bitwise OR would return 0xFFFFFFFF which is casted to le16
0xFFFF or 65535

The problem here is that we expect self->data[self->start] to be
zero-extended while it is not because it is signed.

Cast them explicitly to unsiged chars.

Signed-off-by: Marat Stanichenko <mstanichenko@gmail.com>
Signed-off-by: Pekka Enberg <penberg@iki.fi>