Improve try_get_params method

[saikishor]

Only return true when the parameters are modified and return false for others cases
I've also modified it to use the unique_lock as it is much better than try_lock on the mutex itself.

Related to ros-controls/ros2_controllers#1198 (review)

[sea-bass]

Apologies for the delay -- I'm not really on these repos much these days.

Given this is a change in behavior, I don't feel like I should have the authority to make that decision. I'm going to leave this up to @pac48 as an original author of the package.

[christophfroehlich]

This was introduced with #205, but as discussed in the linked PR I think that it should have a different behavior. We could also deprecated the current one and add the proposed method with a different name if you prefer.

[pac48]

@sea-bass I think the change in behavior makes sense in this case. I think we should merge this.

[nbbrooks]

There are a couple other options I think we should consider here.

1. Make no change, rely on user library to check if __stamp changed to determine if the parameters it once held were old

Perhaps I don't understand the use case here and this is not a solution?

2. Add a new function for the alternative true/false return possibility

Keep the original try_get_params behavior and introduce a new function with the desired, new true/false behavior. Perhaps try_get_newer_params?

Add some brief doxygen to each function to delineate the true/false behavior?

try_get_param - true: your parameters are now up to date

• true: Acquired the lock and either your params were already up-to-date OR your params are now up-to-date.
• false: Failed to acquire the lock

try_get_newer_params

• true: Acquired the lock and updated your params to newer values
• false: Failed to acquire the lock OR there were not newer values (try_get_params would be a confusing name for this behavior IMHO)