First commit of polyline decoder work, still WIP

This compiles and the functions work so it'll do as a baseline / first
commit, but it is some way off being finished and it is not at all
elegant.
Corrections to make decoder work for step 11 back to 5

- eight_bit_chunks expects a list of chunks not a continuous string,
  rename variables to suit...
- but then does get flattened into a string for the eight_bit_chunks_
  sub-function. Makes more sense this way. Maybe
- Fix reversing everywhere (ish, probably could still improve this) to
  suit algorithm requirements
- Add padding function to add zeros to front of binary numbers as
  required to get the correct chunk length
- nthtail usuage was off by one because I didn't realise it starts from
  n+1
Make decoder work back from step 11 to 3

Practically there. Adds in decoding steps 5 to 3. Not sure yet if
checking for last bit being 1 is the correct way to assess if a negative
number (steps 5 and 3), but can investigate that later.

There is also a lot of redundancy I'm sure i can remove. I.e. continual
conversion between binary numbers and the string representation of that
binary number. Some of this may not actually be necessary.
Finish decoding as per the algorithm example steps 11 back to 1

Certainly inefficient and definitely not pretty. But decodes the
example on the Google algorithm page. Yet to test with a full example
where I'm sure I will find bugs.
Fixes for non-negative numbers

But confusingly fixed by fixing the negative numbers which already
worked, but just not the way I thought they were working.

I.e. I forgot bin_flip returns a string so the If statement I had which
just returned Shifted_binary in the case of non-negative numbers would
then fall over on the following steps because it wasn't a string.

Change so this bit just deals in numbers and not strings.

There will be lots of bitslike this where things can be simplified by me
not following the algorithm quite so literally.
Extend to decode a full example polyline (multiple points instead of single)

As per the Encoded Polyline Algorithm Format page:
https://developers.google.com/maps/documentation/utilities/polylinealgorithm

- Previously the decoder only worked with a single point (baby steps and
  all that) and was tested with the example point of `~oia@
- This commit extends it to work with the example of
  _p~iF~ps|U_ulLnnqC_mqNvxq`@
- Probably still to do is figure out decoding an unsigned value and the
  bit about string literals.

Basically alter functions to use a list of lists approach:

- Adds split_up_six_bits which does what it says on the tin and looks
  for the absence of the 0x20 bit and creates a list of lists of each
  point's bit chunks.
- five_bit_chunks is now called six_bit_chunks since the groups of
  chunks have to be split up at the six bit stage.
- Similarly, five_bit_chunk is now called six_bit_chunk; it is otherwise
  exactly the same except from not "un-or-ing" the 0x20 bit to go from
  six bits to five bits. Still padding to six bits, but I wonder if this
  is entirely unnecessary and I can use this to determine the absence of
  the 0x20 bit and thus where to split up the chunks into groups?
- five_bit_chunks now does the "un-or-ing" by mapping over the list of
  lists. Perhaps this could be bundled in with the rest of the big
  lists:map in the top level decode function?
- most of what was in the top level decode function remains the same,
  but is just mapped over a list now. These should probably be at least
  pulled out as separate functions that are mapped over. Need to decide
  which approach to go for: functions that map or mapping functions.
- Changes to reversing, specifically the un-reversing of the five bit
  chunks. This was bundled in with the five_bit_chunks function and the
  un-reversing was achieved by simply not doing lists:reverse since the
  function naturally reversed it. Now, to follow the algorithm backwards
  step by step, there is now a lists:reverse at the end of
  six_bit_chunks which then has to be undone by including a
  lists:reverse in five_bit_chunks.
- Add in algorithm step numbers to comments.
First commit of OSRM API bit to get route geometry

Commiting this in a back-to-front way as I actually first started with
this file before doing the polyline branch. But it was as doing this
that I realised I was going to need a polyline decoder after all because
the API didn't actually return the route instructions and so I'd have to
use the route geometry instead.

So this is just a "works enough to develop further" commit so I can work
on the changes to headsilose.erl next.
Rename function to something more sensible
WIP - 1st attempt at bringing together polyline and OSRM functionality

Compiles, but doesn't yet run.

The general principle is that it will get a previously saved polyline
and convert this into a list of compass headings and distances. It will
then sum up the distances of head, side and tail winds to see which
wins.

For the time being I'm focusing on summing up headwinds only.

Adds the following functions:

- build_list_of_wind_directions

  Previously this didn't exist as a standalone function, rather it was
  built into the main headsilose routine. Before it was fed with a
  direction of travel and based on this it would work out which 16 point
  compass headings were head, side or tail winds. Now it needs to work a
  bit in reverse (although I haven't made the necessary changes yet - I
  don't think1) and instead feed it with the actual wind direction and
  it will use this to build the list of head, side and tail winds.

- get_compass_direction_for

  Convert an angle into a 16-point compass direction

- head_side_or_tail_wind

  Decided whether, for a given direction of heading, it is a head, side
  or tailwind. Uses the lists from build_list_of_wind_directions.
Do head | tail properly

Wasn't thinking straight when I first wrote that, obviously
Make use of atan2 unsigned

Hadn't realised it returns negative numbers.
Merge branch 'master' into osrm

Noticed the nth_wrap problem whilst developing this osrm branch as
building the list of winds would be incomplete.
Yay! Working prototype. Will sum up the distances of headwinds...

...for a polyline route.

I'd made silly mistakes like forgetting which order the list of tuples
were in. I.e {Distances, Wind} or {Wind, Distances}. It doesn't really
matter which order I use, but I should back sure it is consistent and
matches the variable naming.

Now need to extend this to sum up all wind directions and check for
other bugs (such as sum of distances making sense, headwinds are
actually headwinds and not tailwinds, etc).
Extend functionality to sum up all wind directions

by mapping.

Need to tidy up formatting and make it consistent and sort out the
naming of variables - it's such a mess.
Housekeeping: Formatting, variable naming consistency, etc

- Get rid of the mixed up mess of CamelCase, underscores, prefixes,
  suffixes, abbreviations, full names, etc.
- Make indenting of lists:map functions consistent
- Remove spurious whitespace
Calculate wind-type percentages and use to determine win/lose

In other words: done for now. Those are pretty much the changes I
wanted to do. Sure they will be much room for improvements to the code,
but it works!
Handle the reverse route

I don't want to have to query OSRM for th ereverse route - it's
pointless. Instead reverse the route we already have - because I don't
actually need a properly ordered reverse route, just a list of
directions and distances.

In order to do this made sense to re-jig some of the functions a bit:

- Need date and time at top level, not buried in get_weather since
  reverse route or normal route is also dependent on time of day
- Don't convert to distances and compass directions in one swoop since
  it is easier to reverse the heading angles rather than compass points
Commit in haste: Repent at leisure. Fix reverse journey

Had not actually tried out my changes, or, it seems, used my brain at all
in making them.

- Can't simply just add Pi on, need to keep it within 2*Pi limit
- Also forgot to get compass direction
Bug fix - Forgetting than list indexes start at 1

Which means I also need to wrap around the list if I get 16 segments.
I.e. both 0 rads and 2*Pi rads are valid.

This means I probably could have just simply added Pi (previous commit)
to reverse the journey as I can just keep wrapping around. Oh well.
Update README to suit osrm branch