Switch proof to LCMS extendedTransform when BCP is active in display CMS settings.

The LittleCMS softproof transform only has blackpoint compensation(BCP) for the first transform, but not the second. This technically leads to more realistic results, as CMYK profiles describe reflective surfaces, and those reflective surfaces do not allow for blacks as dark as sRGB [0,0,0]. That is, the proofing transform now previews the fact that printer ink is not so black as to be a light-trap.

However, over the past few years there's been several cases where this lead to confusion:

1. Artists do not understand why the softproofing is different from a conversion to cmyk (the latter would use BCP, as that's set by default in the settings)
2. Artists complaining that Krita's softproofing is the worst they've seen in all their software. This means that other (propriatary) software is by default allowing BCP on the second transform as well, as there should not be any meaningful difference between ICC based transforms (with the right intent chosen) between programs because the ICC requires that the profile LUTs are the primary driver of the transformation.
3. People telling me something along the lines that "scribus does have proper proofing", these are people who confuse previewing CMYK images with the "preview printing colors" in the settings of Scribus, in which case, Krita and Scribus were identical. Futher details here.

Now, this switches to LittleCMS' cmsCreateExtendedTransform depending on whether the BCP has been toggled inside settings -> configure Krita -> color management. Said transform has been filled in conform to the actual proofing transform inside LCMS itself.

For reviewers:

1. Please double check that the extendedTransform I'm creating is virtually similar to the official proofing transform in LCMS.
2. Because the proofing transform in lcms also calls extended transform, should I just use a single call to extended transform and remove the seperate path to proofingtransform?
3. The proofing flags are now used as the main flags, but we only really need 3 flags: BlackPointCompensation, GamutCheck and Softproofing. The first is separately tested, the second and third can just be appended to the display flags and that gets sent to the extended transform.

For testers:

1. Please check how you feel about softproofing in this branch with and without Blackpoint compensation turned on in the settings (that is settings -> configure Krita -> color management, not image properties). Note that this requires any intent except Absolute Colorimetric to be used in the softproof settings.
2. This brings up a subtle UX issue: I originally thought that the intents went like this:

Original space -> (transform with proofing intent) -> proofing space -> (transform with display rendering intent) -> display space.

However, it seems that instead it's:

Original space -> (transform with intent that you want to use to convert to the proofing space) -> proofing space -> (transform with proofing intent) -> display space.

In hindsight, this makes sense, as the adaptation used by Absolute Colorimetric (that is, the paper color simulation) only makes sense when its used for the last transform, but it does kind of confuse things, because the transform from image -> proofing space is not so trivial as to default it to Perceptual (most CMYK profiles have a perceptual intent that is not recommended to use by printing proffesionals). Specifically, this would be the "preferred transform" to CMYK, but because we never store any preferred transforms to CMYK I can't really decide on a default here. Because even if we have a second intent, shouldn't we also have this as the default that shows up in the "convert image colorspace" dialog?

Similarly, what should we do about Absolute Intent not supporting blackpoint compensation? Give a warning??? What should said warning say?

Note that the "first" transform controls the gamut alarms (though, it doesn't seem to take into account BCP).

Formalities Checklist

• I confirmed this builds.
• I confirmed Krita ran and the relevant functions work.
• I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
• I made sure my commits build individually and have good descriptions as per KDE guidelines.
• I made sure my code conforms to the standards set in the HACKING file.
• I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.
• Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

/cc @kamathraghavendra @davidrevoy @timotheegiet