Add timer-based propagation functionality to AMCL

[fbattocchia]

Proposed changes

• Add 'increase_propagation' parameter (0-100 Hz) for timer-based propagation
• Implement propagation_timer_callback() for forced propagation updates
• Add update_propagation() method to Amcl class for motion-only updates
• Add comprehensive tests for propagation timer functionality
• Use MutuallyExclusive callback group for thread safety
• Timer disabled by default (frequency = 0.0)

This feature allows for increased propagation rates independent of sensor updates. This improvement allows the implementation of the speed-based motion model

Type of change

• [ ] 🐛 Bugfix (change which fixes an issue)
• [x] 🚀 Feature (change which adds functionality)
• [ ] 📚 Documentation (change which fixes or extends documentation)

Checklist

• [x] Lint and unit tests (if any) pass locally with my changes
• [x] I have added tests that prove my fix is effective or that my feature works
• [ ] I have added necessary documentation (if appropriate)
• [x] All commits have been signed for DCO

[hidmic]

@hidmic I'd like to have a devel or experimental branch in the repository to buffer changes. I'd rather no longer hit main with changes we have not measured to ensure they have an objective reason to exist and to ensure they don't represent a regression by some other measure.

:thinking: I'm on the fence. We don't provide stability guarantees on main. We have release branches and tags for that. How would the transition work? How is it different from ad-hoc feature branches with large patches? I really like the idea of the data driven process for vetting contributions but I want to weigh it against the cost of contribution. It's already difficult to land anything on main, and if we add another gate without a clear process to land a patch (which I know we don't really have, so far it's crafting dedicated experiments and rigs to prove ourselves it's worthy) no one other than us will even dare to try.