refactor HDMapUtils class about routing graph

[HansRobo]

Description

Abstract

• add RoutingGraphType enum class to specity types of routing graph
• add RoutingGraphs class to manage routing graph and paired traffic rule class
• replace EntityType with RoutingGraphType to specify types of routing graph

Background

The current HDMapUtils class uses the vehicle routing graph by default (even for pedestrians).
As the first step to bettter management of routing graph, this pull-request adds RoutingGraphs class.

In addition, the handling of shoulder lanes varies depending on the function, and there is no consistency.
In the future, I plan to develop a unified handling of shoulder lanes by adding a routing graph that includes road shoulders to the better routing graph management added in this pull request.

Details

• HDMapUtils::getNextLaneletIds
  • add type argument to switch routing graph(default: VEHICLE for backward compatibility)
  • two overload has not type argument yet, because it treats road shoulder lanelet.
• HDMapUtils::getPriviousLaneletIds
  • add type argument to switch routing graph(default: VEHICLE for backward compatibility)
    • one overload has not type argument yet, because it treats road shoulder lanelet and has a bug.
• HDMapUtils::getRightLaneletIds
  • replace EntityType with RoutingGraphType in argument
• HDMapUtils::getLeftLaneletIds
  • replace EntityType with RoutingGraphType in argument
• HDMapUtils::getRoute
  • move inplementation into HDMapUtils::RoutingGraphs::getRoute
  • add type argument to switch routing graph(default: VEHICLE for backward compatibility)

References

Regression Test(OK)

Destructive Changes

Although there have been some additions to function arguments, all of this has been carefully implemented to ensure backward compatibility.

Known Limitations

[github-actions]

Checklist for reviewers ☑️

All references to "You" in the following text refer to the code reviewer.

• Is this pull request written in a way that is easy to read from a third-party perspective?
• Is there sufficient information (background, purpose, specification, algorithm description, list of disruptive changes, and migration guide) in the description of this pull request?
• If this pull request contains a destructive change, does this pull request contain the migration guide?
• Labels of this pull request are valid?
• All unit tests/integration tests are included in this pull request? If you think adding test cases is unnecessary, please describe why and cross out this line.
• The documentation for this pull request is enough? If you think adding documents for this pull request is unnecessary, please describe why and cross out this line.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
7 Accepted issues

Measures
0 Security Hotspots
50.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud