Make intersection free lane boundary definition more concrete

[FabianPfeuffer]

Add a description

This pull request makes the definition of free boundaries for lanes more concrete.
It suggests that the free boundaries of an intersection lane should follow a general definition direction (in this case clockwise)

Some questions to ask:
What is this change?

• Documentation/Definition

What does it fix?

• This commit improves the vague definition of the free boundaries. With the current definition of the free boundaries, it is very difficult to e.g. create a closed polygon or mesh for OSI intersection lanes.

Is this a bug fix or a feature? Does it break any existing functionality or force me to update to a new version?

• Only a fix/improvement of the documentation, no update or new version is needed

Take this checklist as orientation for yourself, if this PR is ready for the Change Control Board:

• My suggestion follows the style and contributors guidelines.
• I have taken care about the message documentation and the fields and enums documentation.
• I have done the DCO signoff.
• My changes generate no errors when passing CI tests.
• I have successfully implemented and tested my fix/feature locally.
• [] Appropriate reviewer(s) are assigned.

[yash-shah-asam]

@thomassedlmayer could you please discuss this in the sensor modeling project meeting?

[pmai]

@tbleher you might also have an opinion on whether this is a correct/useful clarification.

[thomassedlmayer]

Is this only about the definition order of the boundary points or also about the order of referencing free lane boundaries in the list (e.g. [11, 14, 13, 12]?