Fix inconsistent string handling in `clib`

[ischoegl]

Changes proposed in this pull request

• Fix instances where clib functions use inconsistent string handling, i.e. ct_getDataDirectories and thermo_report
• Replace by ct_getDataDirectories3 and thermo_report3 that have buffer length and char buffer in last two positions.
• Add threshold to MATLAB thermo report for more compact output (consistent with Python)

The change ensures that a single helper function ctString.m can be used as the interface to pass strings from C++ to MATLAB.

If applicable, provide an example illustrating new features this pull request is introducing

Experimental MATLAB now shows compact report (suppressing minor species):

>> gas = Solution('gri30.yaml')

  gri30:

       temperature   300 K
          pressure   1.0133e+05 Pa
           density   0.081894 kg/m^3
  mean mol. weight   2.016 kg/kmol
   phase of matter   gas

                          1 kg             1 kmol     
                     ---------------   ---------------
          enthalpy             26469             53361  J
   internal energy       -1.2108e+06        -2.441e+06  J
           entropy             64910        1.3086e+05  J/K
    Gibbs function       -1.9447e+07       -3.9204e+07  J
 heat capacity c_p             14311             28851  J/K
 heat capacity c_v             10187             20536  J/K

                      mass frac. Y      mole frac. X     chem. pot. / RT
                     ---------------   ---------------   ---------------
                H2                 1                 1           -15.717
     [  +52 minor]                 0                 0  

Checklist

• [x] The pull request includes a clear description of this code change
• [x] Commit messages have short titles and reference relevant issues
• [x] Build passes (scons build & scons test) and unit tests address code coverage
• [x] Style & formatting of contributed code follows contributing guidelines
• [x] The pull request is ready for review

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 40.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 73.12%. Comparing base (9d0e54a) to head (f8dc0ab).

Files	Patch %	Lines
src/clib/ct.cpp	25.00%	3 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #1760 +/- ## ========================================== - Coverage 73.12% 73.12% -0.01% ========================================== Files 381 381 Lines 54175 54172 -3 Branches 9226 9223 -3 ========================================== - Hits 39615 39612 -3 + Misses 11600 11599 -1 - Partials 2960 2961 +1 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[speth]

What level of compatibility are we trying to maintain for the clib API between Cantera 3.0 and 3.1? So far, I think most of the changes have been consistent with what we do in the Python / C++ interface where user code should continue to work as long as it wasn't using any functions that were deprecated in Cantera 3.0. However, I'd also be OK with adopting a less conservative approach for clib to enable more rapid improvements.

[ischoegl]

What level of compatibility are we trying to maintain for the clib API between Cantera 3.0 and 3.1? So far, I think most of the changes have been consistent with what we do in the Python / C++ interface where user code should continue to work as long as it wasn't using any functions that were deprecated in Cantera 3.0. However, I'd also be OK with adopting a less conservative approach for clib to enable more rapid improvements.

Good question. With the legacy MATLAB toolbox gone, I believe that all of the remaining API's are de-facto "experimental" (.NET is unfinished and Fortran only captures a small subset of features). We can certainly include placeholders so symbols are still in place, but at the same time breaking changes may be a feature. Specifically, I think it's dangerous to use the 3.1 version of the experimental MATLAB toolbox with a 3.0 clib (or, more realistically, a 3.0 experimental toolbox with 3.1 clib). Until we have non-experimental API's that run through clib, I believe we should be able to cycle more rapidly. Changes in this PR are one case in point: the old clib was inconsistent, so specialized calls were necessary for a handful of methods that didn't fit the norm.