IO compartments for graphics libraries

[brooksdavis]

This adds a C18N option to select ports and enables io compartments for each.

I merged libtiff forward to a more recent version from upstream as it's much easier to patch cmake then automake makefiles for this purpose.

The cmake patches aren't what you'd actually want to upstream in that they don't attempt to detect support for the feature, but for ports I think they are good enough.

The libtiff bump may be a bit risky so I've marked the PR as draft for now.

[kwitaszczyk]

I have been wondering if we can come up with a design that would not require modifications in Makefiles and patches of particular ports. For example, if there is a file category/name/policy.json (e.g., graphics/jpeg-turbo/policy.json or graphics/jpeg-turbo/jpeg-turbo.json if we'd like to have unique policy file names) then it is automatically used when building the port without the need to patch port's Makefile/patches to append to linker flags. Mk/Uses/cmake.mk and similar build-system-related files already pass CFLAGS and LDFLAGS that we could reuse for this purpose.

However, I realise now that a port might consist of multiple libraries for which we would like to define separate policies and for which separate LDFLAGS values would have to be constructed. I still wonder if it would be possible to define a single policy file that would be passed to all static linker invocations and the static linker would decide what part of that policy (e.g., based on a library file name) to use for constructing compartments. The policy language already defines a policy for collections of DSOs but I have not experimented with that yet.

Do you think it would be worth exploring this approach to centralise policy-related changes in ports, if not now not to delay this change then at least in the future?

[brooksdavis]

I envisioned the DSOs mechanism as a solution to this problem (I was thinking of abseil.io and protobufs based on the server report, but it should also work in this case were the issue is little utilities). Unfortunately, it's not implemented yet and well below other things on the priority list.

I think what I've done here is closer to what upstreams would want to do most of the time, but not ideal for ports. Once the dsos mechanism is implemented we could look at some sort of magic file name (probably in the files subdirectory). I'm a little wary of that approach from an intentionality perspective, but it certainly would reduce merge conflicts. There is then a question of making sure the policies don't rot...

[kwitaszczyk]

@brooksdavis I've added two main changes to this PR:

1. A port can request using devel/llvm-morello-c18n with USES=compiler:c18n, and we want to use that whenever C18N is enabled in a port
2. A user can define their own COMPARTMENT_POLICY on a command line

Apart from that, there was a typo in a policy for graphics/png. graphics/tiff doesn't build due to the error:

ld: error: input section libtiff/CMakeFiles/tiff.dir/tif_fax3.c.o:.rodata containing local symbol directly accessed by compartment io in input section libtiff/CMakeFiles/tiff.dir/tif_fax3.c.o:.text cannot be assigned due to exported symbol TIFFFaxWhiteCodes

You can squash my commits with yours before we merge this.