Utility: use Corrade String and StringView in ConfigurationValue

[hugoam]

Hello !
We're trying to optimize our compile times and I noticed that StlForwardString.h is actually very heavy on MSVC because it just directly includes <string>, so I thought let's go and try to clean up ConfigurationValue.
I'll open the associated Magnum PR right away. Let me know if I'm going at this correctly 😅

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.94%. Comparing base (6386a97) to head (7c05208).
⚠️ Report is 1051 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #146      +/-   ##
==========================================
+ Coverage   97.92%   97.94%   +0.01%     
==========================================
  Files         132      133       +1     
  Lines       10749    10746       -3     
==========================================
- Hits        10526    10525       -1     
+ Misses        223      221       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mosra]

Hi and sorry for a late reply -- I've been away last week and only now catching up to everything.

This makes sense in general, and especially the new ConfigurationValueStl.h header does. That's how I'd do it myself as well. But the reason I neglected this part was because all APIs that actually used ConfigurationValue use std::string themselves heavily, so until I clean those up I didn't really see how fixing it just here would improve anything. Can you say where it helped in your case?

Oh, or is it just due to Mesh.h, PixelFormat.h and VertexFormat.h dragging <string> in (on MSVC), according to what I see in mosra/magnum#582? Because there it relies just on a forward declaration of ConfigurationValue and could thus be changed to String / StringView without needing to modify anything else. The Math/ConfigurationValue.h is a separate header that isn't pulled in by anything else, so it shouldn't affect your build times.

(For the rest, I feel it wouldn't really improve anything until Utility::Arguments and Utility::Configuration are de-STL-string-ified first. So I'd keep these PRs around until I get to cleaning that up.)

[hugoam]

Oh, or is it just due to Mesh.h, PixelFormat.h and VertexFormat.h dragging in (on MSVC)

Yes, exactly, that was the low hanging fruit I was trying to tackle to improve compile times as those are some pretty commonly included headers, and have them drag in <string> induces a pretty big cost. So yep downsizing those PRs to just changing those 3 headers would be perfectly fine for us ! Unless obviously there is something else that we commonly include that I missed

[mosra]

Done! Leaving the PRs open, will merge the rest once I get to cleaning up Utility::Arguments and Utility::Configuration.