Document and improve wavemap configuration

[victorreijgwart]

New features:

• Write documentation page on how to configure wavemap
  • Preview of new docs available here
• Indicate the unit of config members (e.g. min_cell_width in meters) using types
  • This replaces the previous solution that used enums, which were stored and handled separately
  • With this new solution, the units directly and clearly show up in the documentation
• Make warnings/errors that can occur when loading configs more descriptive
  • When loading a param fails, print an explanation, including
    • The offending param's name and type
    • The action that will be taken (e.g. it will be ignored, and default value X will be used instead)
• Update all example configs
  • Make sure syntax matches newest wavemap version, addressing Issue The livox online config  #24
  • Apply recommended settings
• Define a schema for wavemap configs using jsonschema, which also supports YAML, to enable
  • Text completion, inline documentation, and real-time validation when editing wavemap configs in IDEs like CLion
  • Automatic linting of wavemap configs through .pre-commit hooks
• Do not emit CMake warnings when the optional livox_ros_driver2 dependency is not found (contributed by astumpf).
  • If users try to initialize a pointcloud input of type livox but the driver is not installed, they will be prompted to install it.
• Add templates for GitHub issues and pull requests

Notes for the review:

• The most important changes to review are in the docs/pages directory. The rendered new docs can be explored locally by downloading this archive, unzipping the artifact.tar it contains, and opening the index.html file in a browser.
• I realize that the usage of exceptions would be more appropriate than using std::optional<Config> return values, but introducing exceptions is a breaking change I would rather properly look into later.
• If you're pressed for time, the newly added jsonschemas are the least critical to review. These are currently mainly used internally (e.g. to show a warning when an example config is invalid) and don't directly affect users. In general, they just express how the configs are structured and nested. The descriptions they feature for each param are identical to their Doxygen descriptions (also shown on the Configuration page in the docs).

[victorreijgwart]

/prepare-release minor

[LionelOtt]

I'm not sure that asking for a solution description is needed or beneficial, as that might just result in unusable ideas. I would however have a section that asks what that feature is supposed to be useful for.

[victorreijgwart]

I rewrote this template from scratch, hopefully it's better now.

[LionelOtt]

Is YAML list correct given all this is JSON?

[victorreijgwart]

Assuming that people will primarily use wavemap with ROS, the settings would be specified in ROS config files (YAML).
The only place where we currently use JSON is when defining the schemas for wavemap configs, which are defined using the jsonschema standard. These schemas are used for linting (pre-commit) and can be used to simplify config editing (in CLion), but don't affect wavemap's runtime.
Based on your comment I briefly considered changing "YAML list" to just "list", but I think it's good to keep the former s.t. users can quickly find the syntax they need for YAML lists on Google. Let me know if you agree/disagree :)

[LionelOtt]

The documentation looks good, and I like the entire "make it hard to mess things up with typos and unit errors".

[victorreijgwart]

Thank you @LionelOtt for reviewing, and astumpf for contributing!