meson: install header and pkg-config file and in subprojects

[stephanlachnit]

What does this change do?

Install the headers and the pkg-config file also in Meson subprojects. The reasoning behind this is that if you install a Meson project using TOML++ (potentially into a non-standard location like /opt/project), and also create a pkg-config file for your project, TOML++ might get added as public or private dependency. In that case, the header (and pkg-config file) should be installed.

Is it related to an exisiting bug report or feature request?

No

Pre-merge checklist

• I've read CONTRIBUTING.md
• I've rebased my changes against the current HEAD of origin/master (if necessary)
• ~I've added new test cases to verify my change
• I've regenerated toml.hpp (how-to)
• I've updated any affected documentation
• I've rebuilt and run the tests with at least one of:
  • Clang 8 or higher
  • GCC 8 or higher
  • MSVC 19.20 (Visual Studio 2019) or higher
• I've added my name to the list of contributors in README.md

[marzer]

The reasoning behind this is that if you install a Meson project using TOML++ [...] TOML++ might get added as public or private dependency.

The word "might" is the operative one here - in my experience most subproject usage is just to bring in a dependency for internal use, so this is likely going to be problematic for many (me included - this would complicate one of my workflows on Windows).

I'd happy accept a version of these changes that left the current behaviour as default, and added some meson option to enable all the install-ish bits even as a subproject, though. I think that's a good middle-ground.

[stephanlachnit]

this is likely going to be problematic for many (me included - this would complicate one of my workflows on Windows).

I'm not entirely sure how this would complicate any workflow - it just is an additional header and file? I guess on Windows you most likely don't want to install any header anyway, in which case installation tags are the better option any.

[marzer]

I'm not entirely sure how this would complicate any workflow

Welcome to hyrum's law. This library has many users - the current behaviour is an interface, and your change will almost certainly be breaking that interface for someone.

As noted above, I won't accept this if you change default behaviour. Please modify it per my request above, or close your PR. Thanks.