Use std::mutex instead of std::recursive_mutex in IWearRemapper

[RiccardoGrieco]

This PR introduces the following 2 changes in IWearRemapper:

• Fixed use of mutex when reading the port in https://github.com/robotology/wearables/pull/174/commits/d90cc76692e545ba5e9a41a3227a5ee4a8ae01a1
• Switch to use std::mutex instead of std::recursive_mutex in https://github.com/robotology/wearables/pull/174/commits/3c3a4d7902aba66e86e1384277ad294700fe1413
• Fixed first read check from all ports in https://github.com/robotology/wearables/pull/174/commits/9661562c8695de64482e8fab88a1568424bd1902

[lrapetti]

@RiccardoGrieco let me know when the PR is ready to be checked (in latest tests was not working properly)

[RiccardoGrieco]

As per discussion with @lrapetti we will implement the following changes:

• [x] Add a parameter (something like allow_dynamic_data) that will allow the module to change the number of wearable sensors exposed by the Remapper at runtime. If the parameter is negative after some first reads from the port, the list of exposed sensor will always be the same. In the second case, the module will need less synchronization points as the underlying map buffer won't change.
• [x] Implement two version of the data update depending on allow_dynamic_data.
• [x] Check if the changes bring actual performance improvements. Tested and it doesn't seem to bring noticeable performance improvements (at most 100 microseconds)

[RiccardoGrieco]

With b0d1127 I also switched from std::map to std::unordered_map. The first one has an access time that is O(log(n)) w.r.t. the number of sensor, while the second one's access time is O(1). Since we do not have cases where the order is important, it seems safe to me to switch to that one.

[RiccardoGrieco]

Thanks @lrapetti, merging.