osltoy - Feature Request: custom #include search paths

[maxwelliverson]

Description

For Dev Days

#1862

Addressing a osltoy feature request, I've added the ability to specify custom search paths.
The changes consist of the following:

• Added a command line option -I <path> to specify search paths (OIIO::ArgParse unfortunately can't mirror OSLCompiler's -Ipath syntax)
• OSLToyMainWindow now stores an array of OSLCompiler options alongside a flag indicating whether or not they should be regenerated before compilation. The only option currently able to be specified is -Ipath, but this should ease any future extension.
• Added a GUI component consiting of a window with a mutable list of the current set of search paths. This list is initially populated with any paths passed via the command line, but any modifications to the list will be reflected when the shader is next recompiled. Modifying this list does not currently force recompilation.
• Added an entry to the Tools menu to open the new GUI component.
• Added a line of output to the error window indicating what options the compiler was invoked with. I've defaulted to having it print for every run, but this may want to only print on failure.

Tests

I did not add any automated tests for this feature, as is consistent with the rest of osltoy. I did, however, do some manual testing to make sure the functionality works as expected.

Shaders that failed to #include some file instead succeeded when the parent directory of that file was added to the list of search paths via both the command line and the GUI component. Respectively, when said search path is then removed via
the GUI component, any subsequent compilation attempts fail again. The GUI component otherwise behaves as expected.

Checklist:

• I have read the contribution guidelines.
• I have updated the documentation, if applicable.
• I have ensured that the change is tested somewhere in the testsuite (adding new test cases if necessary).
• My code follows the prevailing code style of this project. If I haven't
  already run clang-format v17 before submitting, I definitely will look at
  the CI test that runs clang-format and fix anything that it highlights as
  being nonconforming.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: maxwelliverson / name: Maxwell Iverson (65fd7d4, c7ac4f1, 7fb1b85)

[maxwelliverson]

/easycla

[lgritz]

As a style nit, we tend to only put blank lines within a function body where the extra whitespace is clarifying -- for example, if you have several code statements that are doing a well defined task A, followed immediately by several statements that do a separate task B, then a single blank line between them can help understanding of the conceptual grouping of the lines into tasks. But if the space doesn't especially clarify the algorithm, you may as well omit it and benefit from the function being compact. Also, even when whitespace makes it more clear, a single line suffices.

(I'm referring to WITHIN a function body. I also like a single line between function definitions of a class definition. But any freestanding functions, my personal preference is 3 lines between functions.)