RFC: Exposing config hashes within a user facing tool

As part of our work in the config group, as well as the potential internal configuration files, I have been trying to think about the implications for users of having more ways to use configs and the implications of what happens when they are shared between different users. For instance:

- How would we validate that an external config is the same as an internal one.
- Would we want to be able to tell the difference between a "white space" change like line endings being switched
- What about other non-functional changes like a description change or other comments

It appears that having an ability to more easily compare the text hashes of a pair of configs would be useful at least in the internal library vs an external one, without archiving/exporting the internal config and then doing our own hash or diff.

For functional differencing, I see the minimum we should probably look to achieve is to document ways of using the existing cache IDs, but it would be nicer if we could provide the users with either a python script or perhaps more ideally a small executable (part of ociocheck ?), that could do some of this for them. (File path hashes are less useful when sharing config

I consider it more important to provide a tool if we agree that being able to determine functional equivalence is useful.

### Complications

- If you reorder colour spaces in a file does it match?
- What about other items that also have an implied meaning in the order like traditional displays and views?

I'm of the opinion that we should not embed the hash with the config as we would have to add complexity to ignore the text of the hash, etc.