Improve CGMES importer logs

[jeandemanged]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• A PR or issue has been opened in all impacted repositories (if any)

Does this PR already have an issue describing the problem?

No

What kind of change does this PR introduce?

"inconvenience" fixes

What is the current behavior?

lots of confusing logs:

• Mostly about Operational Limits ending in practice in the following form:

   Pending: Operational limit. Reason: Not assigned for ShuntCompensator 123. Limit id, type, typeName, subClass, terminal : 456, LimitTypeKind.tatl, someName, CurrentLimit, ab123
   Missing: Terminal 456 or Equipment null at OperationalLimit TATL20 (def). Reason:
  

  Caused by OperationalLimits on equipements not supported. For switches we get only the second message.

• logs with an empty reason end with <some issue> . Reason:

• superfluous warning about missing name on cim:TieFlow-s

• superfluous warning cim:Switch connected to boundary point (perfectly valid in CGMES, and supported by the importer)

What is the new behavior (if this is a feature change)?

• added option to enable/disable logging of unsupported operational limits. Disabled by default.
• Operational Limits for unsupported equipment are clearly logged
• suppressed warning of missing cim:TieFlow name
• warning about switch connected to boundary point changed to debug level
• messages with empty Reason do not end with ... Reason: anymore.

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

Other information:

[jeandemanged]

I would change this to just an info log, or even debug, or even remove completely, this behavior is described in the CGMES import documentation here.

[rcourtier]

This generates a warn severity level log, which is usually used when an inconsistent or incomplete data is fixed. Here there is no inconsistency, this is the standard conversion process and it is documented as you pointed out, so I'm ok to change this to an info severity level log.
I think however it is important to keep this as an info and not a debug log, as users often tend to hide the debug logs and they might struggle to understand why their CGMES boundary switch is not visible in the IIDM switches.

[jeandemanged]

still some uncovered cases about OperationalLimits ... returning to draft

[sonarqubecloud]

Quality Gate failed

Failed conditions
75.7% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[rcourtier]

This generates a warn severity level log, which is usually used when an inconsistent or incomplete data is fixed. Here there is no inconsistency, this is the standard conversion process and it is documented as you pointed out, so I'm ok to change this to an info severity level log.
I think however it is important to keep this as an info and not a debug log, as users often tend to hide the debug logs and they might struggle to understand why their CGMES boundary switch is not visible in the IIDM switches.