pluginlib usage for registering plugins

[emersonknapp]

Is your feature request related to a problem? Please describe.

Right now, users need to provide (potentially long) explicit lists of plugin libraries to load, in order to extend the available node inventory.

navigation2 is one such user, that employs a fairly complex strategy to make sure all available plugins are loaded by the factory

• Its CMake renders a list of plugin library names to a header file as a compile-time constant
• That value is then used at runtime https://github.com/emersonknapp/navigation2/blob/main/nav2_bt_navigator/src/bt_navigator.cpp#L67 to load the plugins by name, with an optional parameter that contains a list of extra plugins that the user has requested

Describe the solution you'd like

Instead of all this extra accounting, we can increase flexibility by a lot by using pluginlib.

I have already built a fully functional solution, available at https://github.com/polymathrobotics/behaviortree_cpp_pluginlib/tree/main/behaviortree_cpp_pluginlib - this eliminates most of the complexity of getting arbitrary plugins into a behavior tree factory.

The package works fine standalone as it is, but I believe users would be served better by including this functionality in the behaviortree.cpp core and recommending it as the default plugin pattern. Do you agree? If so, how do you think that code fits into this repository?

1. Allows distributed export of any number of extensions, within a single library
2. Allows automatic discovery and loading of plugins by the factory, without any behaviortree.cpp-specific special accounting

See the README for the usage pattern proposed here.

Describe alternatives you've considered

One could write a custom plugin system with discovery, but it would be reinventing a lot of wheels that pluginlib/classloader already provide.