Source-code Merge Request #8: Add possibility to load xml files from custom source (open)

With these changes files may be loaded from custom sources (not only filesystem) or may be genereted on the fly.
Data provider should allocate and free up memory for xml source data, gutenprint doesn't control this

[Solomon Peachy]

Is the intent here to pass XML data in on the fly?

But regardless, I'm not sure this can be accepted in its current form -- it adds global state that affects multi-threaded use of libgutenprint. All "global" state should be encapsulated within the stp_vars_t structure instead.

[Alexander Guz]

Is the intent here to pass XML data in on the fly?

Not only. First thoughts were about loading data from embedded resources or network services, but now I think about setup any printing parameters using xml. For example, I want to setup inks with custom head offset values. With this functionality I don't need implement additional functionality, I can modify existing xml easily with golang or c++

But regardless, I'm not sure this can be accepted in its current form -- it adds global state that affects multi-threaded use of libgutenprint. All "global" state should be encapsulated within the stp_vars_t structure instead.

I think there is no global state, it works like callback, like existing stpui_set_thumbnail_func/stpui_set_thumbnail_data