Util improvements

[tfc]

Motivation

This PR contains additional random enhancements of the code:

• using the npos member variable instead of the static variable within the type, which makes the code more generic
• the stringsToCharPtrs does some really unsafe const casting. I changed its signature to be safe and then added const_casts at the caller side where C-style functions are used that make the const casts necessary. This makes the stringsToCharPtrs function safer to use.
• Generelly removed some C-style casts
• dropped parentheses from lambda expressions that accept no parameters
• slightly improved some string-handling functions
• removed a std::make_unique call. the reason is that make_unique tries to allocate the unique pointer and the managed object in one chunk of heap memory. in this special case this is not advantageous because we're dropping the pointer just to transfer the management into a new unique pointer.

Context

Priorities

Add 👍 to pull requests you find important.

[Ericson2314]

@tfc And I discussed how based on the bind manpage it seems the size of the un-upcasted type should be specified.

I think they might be all the same size, but if the upcasted one was larger to support other variants this could be necessary.

[roberth]

One suggestion, but otherwise lgtm. Needs a rebase since #8920

[Ericson2314]

@tfc I have some some tricks to make the rebase over a big split like #8920 less painful btw. git show > foo.patch, and then sed 's/old_name/new_name/' < foo.patch | patch -n1 basically. The rejected hunks can then be used instead of foo.patch for the next new_name until every hunk has been fanned out to the right split new file.

Let me know if that helps!

[Ericson2314]

I used my tricks to rebase on top of #8920

[Ericson2314]

("improv" is conventionally short for "improvisation" not "improvement(s)"; I think you meant the latter.)

[tfc]

@Ericson2314 thank you so much for rebasing!
@roberth i deduplicated this casting comment.

i also rebased on the latest master commit again.
Is this good to go?

[roberth]

CI says

error: executing 'git': Bad addres

Might this be caused by the command.cc / environ changes?

[Ericson2314]

Perhaps it is easiest to split up / bisect / reorder to find, if the commits should work in isolation.

[Ericson2314]

Of course we need to make it pass first, but otherwise I see nothing wrong.

[tfc]

@Ericson2314 bisect indicates that it was the commit where i made the const casts more obvious. i guess that patch didn't age well over the rebases.

it's now all nicely rebased and i dropped that specific commit to add it later.