fix nim CI; fix local testament

[timotheecour]

• fix running testament locally on OSX, doAssert execShellCmd("brew install gtk+3") == 0 would fail if that package was already installed
• fix nim CI for important_packages.inim pending inim breaks nim CI inim-repl/INim#74
• fix nim CI for thttpclient_ssl.nim (misc CI flaky tests timotheecour/Nim#113 (comment));
  on OSX the SSL error is printed to stderr and there's no way to capture it:
  123145372754092:error:14035418:SSL routines:ACCEPT_SR_CERT:tlsv1 alert unknown ca:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.11.1/libressl-2.5/ssl/ssl_pkt.c:1205:SSL alert number 48

none of these worked:

proc ERR_lib_error_string*(e: cint): cstring{.cdecl,dynlib: DLLUtilName, importc.}
proc ERR_func_error_string*(e: cint): cstring{.cdecl,dynlib: DLLUtilName, importc.}
proc ERR_reason_error_string*(e: cint): cstring{.cdecl,dynlib: DLLUtilName, importc.}
proc ERR_error_string_n*(e: cint, buf: ptr char, len: csize_t){.cdecl,dynlib: DLLUtilName, importc.}

but checking for routines:CONNECT_CR_CERT:certificate verify failed seems correct according to https://mta.openssl.org/pipermail/openssl-users/2017-December/007046.html /cc @FedericoCeratto

SSL alert number 48 is specified in the documents that define SSL/TLS. It is the code for "unknown_ca", which means that verification failed

note

remaining CI failures (Nim SSL CI) are pre-existing ; these pipelines only run when affected code is modified but the failure is unrelated

[narimiran]

Why this comment? #10558 has been rejected.

[timotheecour]

I intend to re-open and rebase this PR in the near future, I keep running into cases that calls for this feature, which is available with doAssert cond, msg

The rationale that was given for rejection Tests and suites already have names. does not take this kind of situation into account, where the context (a runtime value!) only makes sense to show in the failure msg. As you can see in the above code, that context can't be shown in test suite name (and it wouldn't make sense either). We also don't want to dump context unconditionally, but only on failure, which is exactly what #10558 was implementing.

When this feature will be available, you'll be able to write the natural check(condition, msg), and you'll know why a test failed without having to modify it and run it locally, saving time.

[narimiran]

I intend to re-open and rebase this PR in the near future

Ok, but this PR (or Nim codebase in general) shouldn't be your personal to-do list.