Report LLDB version and clean up LLDB-MI launch sequence

[jld01]

We use CLI 'version' to replace the MI '-gdb-version' command.

Relates to: #1186

[ruspl-afed]

Ah, I missed the moment when it became "ready for review". However let me ask my questions anyway:

1. do we continue to introduce new non-final public types (and what for)?
2. does this API change fully comply with the https://github.com/eclipse-cdt/cdt/blob/main/POLICY.md#api ?

[jld01]

Hi @ruspl-afed, you wrote:

1. do we continue to introduce new non-final public types (and what for)?

I am following the existing DSF conventions for reasons of consistency here. If you think we should adopt a more restrictive policy, I suggest raising a new discussion topic.

2. does this API change fully comply with the https://github.com/eclipse-cdt/cdt/blob/main/POLICY.md#api ?

I think it does, yes.

[ruspl-afed]

I mean this section (since we have an addition to org.eclipse.cdt.dsf.mi.service.command.CommandFactory)

https://wiki.eclipse.org/Evolving_Java-based_APIs#Example_4_-_Adding_an_API_method

However, if the method is added to a class which Clients may subclass, then the change should ordinarily be viewed as a breaking change. The reason for this harsh conclusion is because of the possibility that a Client's subclass already has its own implementation of a method by that name. Adding the API method to the superclass undercuts the Client's code since it would be sheer coincidence if the Client's existing method met the API contract of the newly added method. In practice, if the likelihood of this kind of name coincidence is sufficiently low, this kind of change is often treated as if it were non-breaking.

[jld01]

Yes. In practise, it is not particularly unusual for the likelihood of name coincidence to be considered sufficiently low that the change is treated as non-breaking.