Inflection-206 Fix missing ICU UTF-16 header includes, C++17/20 CTAD guides, and empty INFLECTION_ROOT path resolution

[nciric]

Fixes #206

Summary of Changes

This PR improves compiler portability and C++ template deduction compatibility across inflection:

1. Explicit ICU <unicode/utf16.h> Includes:

   • Explicitly #include <unicode/utf16.h> in 8 source files (ControlCleaver.cpp, TokenUtil.cpp, StringViewUtils.cpp, UnicodeSetUtils.cpp, StringFilterUtil.cpp, and Hebrew/Korean/Turkish grammar synthesizers) that use UTF-16 code point macros (U16_PREV, U16_GET, U16_LENGTH, U16_NEXT).
   • Resolves build failures on hermetic toolchains and IWYU-strict environments where ICU sub-headers are not transitively exported by <unicode/uchar.h> or <unicode/ustring.h>.

2. C++17/20 Template Argument Deduction (CTAD) Guides & Test Fixes:

   • Added user-defined deduction guides for Finally, CompressedArray, and MarisaTrie to allow clean class template deduction from constructor arguments (e.g. lambdas, std::vector<T>, std::map<..., T>).
   • Explicitly specified std::atomic<bool> and std::barrier<> in DialogThreadSafetyTest.cpp.
   • Resolves compilation failures and warnings when building under -std=c++20 with LLVM libc++ or when -Wctad-maybe-unsupported is enabled.

Verification

• Builds and unit tests pass cleanly across Linux, macOS, and Windows CI.

[grhoten]

This type of change seems to be overly cautious, but it's OK to include.

[nciric]

I get hard errors if I don't

error: use of undeclared identifier 'U16_PREV', error: use of undeclared identifier 'U16_GET', error: use of undeclared identifier 'U16_LENGTH'

[grhoten]

This feels like a false alarm.

Do you really need to support -Wctad-maybe-unsupported? The code passes its tests on Linux, macOS, and Windows. It seems to work with g++ and clang++. What OS/compiler combination would fail for this configuration?

If you have a concern about portability to other operating systems like Windows, there is a long list of warnings from the MSVC compiler that could be addressed to improve portability to that operating system.

[nciric]

The -Wctad-maybe-unsupported is on by default and developers in specific environment can't override it, so it's a hard requirement for me.

[grhoten]

Instead of this wonkiness, can we just go back to the older C++14 style where it's explicit at the call site? That's how it used to be called before my editor was trying to suggest modern syntax.

If this is a requirement, then -Wctad-maybe-unsupported should be added to CMakeLists.txt to avoid the issue from being reintroduced. Perhaps it can be around lines 65-68 with the other compiler warnings. That's around where -Wglobal-constructors -Wexit-time-destructors is also used.

[grhoten]

FYI the -Wweak-vtables is defined there too due to a nefarious bug involving multiple vtables defined in a library with full link time optimization turned on. Using unique vtables this way also makes the library slightly smaller.

[nciric]

Done

[nciric]

Thanks @grhoten! I've updated the PR per your suggestion:

1. Reverted the deduction guides from the header files (Finally.hpp, CompressedArray.hpp, MarisaTrie.hpp).
2. Made template parameters explicit at all call sites across tools/ and test/.
3. Added -Wctad-maybe-unsupported to CMakeLists.txt under Clang compile flags to enforce explicit template parameters going forward.