Bangle.js 2 Cutting Edge - new heart rate algorithm

hello again, some news about the new algorithms benchmark.

Data: we have prepared a data collection protocol, we aim at 20 people, doing different activities, both on treadmill and outdoor walking. The protocol will get an ethical approval from Politecnico di Milano. Right now we don't have the permission to publish the data, but we are planning to obtain it. I understand that the data is what you would mostly appreciate, so I am keen to publish those files, but it may take some time. We are planning to acquire the data at its default sampling frequency for both acceleration and PPG. Would that be OK for you, or would it make more sense to acquire at higher frequencies, in case you want to test out different frequencies?

Tests: the repository for the tests that you have may need some adaptation though. We are starting with the step counter and we can already see some changes to make. Concretely:

1. the main.c needs to be adapted to be able to run different algorithms, not just 2 (espruino and "original"), we are going to change it and make it more general. I hope that it's OK?
   
2. in terms of output, I would suggest to print out just the totals, comma separated, then that could be copied into a spreadsheet where all sorts of statistics can be done. Or we add stats to main.c, but maybe after the totals.
   
3. algorithms would go into a dedicated folder, that includes moving the "original" algorithm into its own .h/.c files instead of being mixed within main.c. We can keep the espruino one linked from the Espruino code so it's always upated to the last version.
   
   

If you are OK with these, we will be sending pull requests, as we advance with the task. You can of course review those and suggest changes if there's anything you don't like.

Another issue: from what I understand the current API for the step counter (stepcount_new(int accMagSquared)) return a 1 if a step is detected or a 0 otherwise (and in some cases it tries to make up for lost steps too? haven't studied this well yet). I would suggest to change the signature to something that is more generalisable for other algorithms, for example instead of returning the "new" steps, it would return the total step count, since the algorithm was inited (or reset) and instead of accepting the magnitude as argument, it could accept the raw x, y and z. I know that this has repercussions in many places within the Esrpuino code, so it's a lot to ask, but it would make the signature compatible with algorithms that are based on different approaches. Let me know how doable this would be. We can of course decide later, if and when we have some good alternative candidate algorithm.

Thanks!