Implement delay command for BMP180 peripheral pressure function

[Fleker]

@polfeliu here's a preliminary commit.

There are still some issues to reconsider in this implementation, as with the BMP180 pressure function using a delay, it cannot 'return' the pressure variable in the same way. So for Espruino as an example, there needs to be some manner to implement a callback.

For the generic embedded case, there also needs to be a delay callback that is added to the methods to get that back. Also there isn't any time delay implemented at all, as it can vary wildly. So that is going to require more thought.

For the Kubos impl, I think the time.h import should go in the header file rather than the source file. That's a simpler fix.

[Fleker]

Add JS support for delays. I've added a name field to a delay in order to use it to name the callback that is required. This will not work for nested delays, nor will it work for more than one delay. Any other callback won't work either. But for the BMP180 this implementation will work.

Embedded C & Kubos changes are next.

[Fleker]

I've added the embedded c callback, which is highly abstracted such that you can plug the callback into your custom scheduler as a function pointer. The BMP180.c example shows how the callback is executed.

This still has some issues with regards to variable declarations, because the callback looks for local variables which are not defined.

[Fleker]

How do I save variables from the first function and allow you to plug them into the second? If the first function returns a function pointer, there is no more external content sent back.

Going to consider returning a struct which can contain more than one variable of more than one type.

[Fleker]

I've moved to a struct architecture for callback state to embedded C, which is going to be more scalable and easier to pass into the callback.

[Fleker]

@polfeliu I don't know if you have any more thoughts about the delay spec structure. There are a few examples in this commit for how it will look on different platforms. I'll keep this PR open a bit longer to see if there's any discussion to be had before merging, as this is a bit of a significant change.

[polfeliu]

Looks good! I look forward to create my own template for stm32 & FreeRTOS

[Fleker]

Merging in with some last-minute improvements.