feat(autoware_sensing_msgs): implemented the proposed universal radar messages

[knzo25]

Description

This PR implemented the universal radar messages discussed in
https://github.com/orgs/autowarefoundation/discussions/5264

How was this PR tested?

Used together with tier4/nebula#284
to check the field contents

Notes for reviewers

None.

Effects on system behavior

None.

[github-actions]

Thank you for contributing to the Autoware project!

🚧 If your pull request is in progress, switch it to draft mode.

Please ensure:

• You've checked our contribution guidelines.
• Your PR follows our pull request guidelines.
• All required CI checks pass before marking the PR ready for review.

[knzo25]

Reference: https://github.com/autowarefoundation/autoware_msgs/blob/main/autoware_perception_msgs/msg/DetectedObject.msg

The one think I am over the fence on is about whether we should normalize the probabilities for [0.0, 1.0] or keep them [0.0, 100.0]. How do you guys think?

[xmfcx]

What about updating https://github.com/autowarefoundation/autoware_msgs/blob/main/autoware_perception_msgs/msg/ObjectClassification.msg
list with these items? We could avoid creating a new classification message and duplicating information.

Also, what are hazard, over drivable, under drivable? And why are they radar specific?

[xmfcx]

The one think I am over the fence on is about whether we should normalize the probabilities for [0.0, 1.0] or keep them [0.0, 100.0]. How do you guys think?

I am very surprised someone actually used 0->100 to represent probabilities. At least, any new implementation should have them normalized 0->1.

[mojomex]

It's probably worth it to write have a small support library that

1. ensures that RadarInfo is received before any RadarObjects are handled
2. provides accessors for RadarObject fields that auto-convert/validate using the received RadarInfo

It seems quite easy to screw up as a user of these messages otherwise - e.g. orientation, is it deg, rad, something else?

[mojomex]

Instead of a dummy value we should most probably use NaN

[mojomex]

Not sure if these values are chosen for backward compatibility, but e.g. Protobuf recommends to make 0 the invalid option such that any zero-initialized message is invalid by default.