Remove deprecated score::StringLiteral

[crimson11]

Removed usage of deprecated
score::StringLiteral in Runtime.
Replaced with const char* and
added verification for NULL-termination.

[limdor]

const char * has multiple problems and I do not think this should be the substitute for StringLiteral.

• An std::string can be converted implicitly from const char * ending with dynamic memory allocation
• const char* has the problem that it could be a pointer to characters or a pointer to an array of bytes. char meaning is way too overloaded in the standard
• The fact that it is a pointer, it can end up in all the issues with pointer decay
• It has no notion of being null terminated or not

Because of that, my proposal would be to go for better alternatives.

• For main arguments, go with a container of null terminated string views. We can use https://github.com/eclipse-score/baselibs/tree/main/score/language/safecpp/string_view and https://github.com/eclipse-score/baselibs/blob/main/score/string_manipulation/arguments/arguments.h for that.
• For global constant string literals with internal linkage, we can use zstring_view https://github.com/eclipse-score/baselibs/tree/main/score/language/safecpp/string_view
• For the rest, I would propose to take a look one by one, depending if they are owning or not, and depending if they are null terminated or not.

Additional note: I saw that in several places you removed the usage of StringLiteral, but the dependency to the target and the include is still there. If we remove StringLiteral we should remove it completly and also remove the include files. Of course it can happen that we break some code if someone relies on the transitive dependency but imho this is a price the users need to pay if they did not have proper includes.

[limdor]

This is something that you cannot do. The problem of this is that if it is null terminated, you will find it, but if it is not null terminated, you hit undefined behavior.
In the second case, it could even be that you hit some null character in memory that it is totally unrelated.

[LittleHuba]

Please use C++ infrastructure. E.g. zstring_view or Arguments helper in baselibs.

[crimson11]

OK. I guess, I will close this PR then. The thing is: All the usage of const char* stems from the main() entry-point! I.e. there you get const char*, which are guaranteed to be NULL-terminated.
I don't know, how to fix the "issue" then! We expect the user to hand over the char* he gets from the OS in main(). If you now want me to change the signature from our PUBLIC API, where the user currently hands over these char* from main() ... I can't do it.

@limdor , @LittleHuba : Maybe I'm wrong, but to me it seems, that all your input means/can only solved via changng the PUBLIC interface. I.e. require the user NOT to hand over the char* he gets from OS (cmd-line-args) .... if he then also needs to transform these char* to somethings else what is discussed here ... this might also mean eventually heap-allocation ...?

[limdor]

Yes, it means breaking public API. But the first step would be to provide a second overload that allows the user to use a container of zstring_view and deprecate the API that uses const char *.
And yes, depending how we do it, it might require allocation at startup for the container, but it can also be an allocation aware type.