feat: Update c2pa.py

[tmathern]

• Update c2pa.py with latest changes from the POC branch
• Update makefile
• Clean up tests so resources are properly released

[tmathern]

So we can run this from the root of the repo. I used this instead of build.py because build.py seems broken, whereas that one works. Let me know if build.py was meant to stay or not - but then it likely needs debugging.

[gpeacock]

I did work on build.py to get it functional, but I can merge that in.

Can you re-review?

[gpeacock]

There's a lot here. I added some feedback. Let me know what you think.

[gpeacock]

I did work on build.py to get it functional, but I can merge that in.

[gpeacock]

This feels odd to me. handle_string_result is designed specifically to return string results on methods that return strings. Using it everywhere when you already know you want to return an error is confusing. why not just call handle_c2pa_error if that is what you know you are doing?

[tmathern]

There is no handle_c2pa_error in that branch... ? Maybe in your branch... (I'll check and update if I see it there (not found?))? And I keep having to check _lib.c2pa_error() to not miss any error (remember we had the case where an error string would be reported there, but raise no error, or the called function's result would report being ok...). This is the additional layer to not miss any error with the current setup.

[tmathern]

I renamed _parse_operation_result_for_error but I am not totally sure we both aim for the same thing here. I aim to throw errors when errors happened (what _parse_operation_result_for_error now does), but you want to return strings? Returning strings may be an unexpected way to handle errors for people in Python more accustomed to dealing with exceptions being thrown.

[gpeacock]

I definitely want to throw errors when they happen! I created a bunch of odd little macros to handle things reliably in the Rust C binding logic. They are oddly named and I need to document them and explain how they work. I've tried to follow old school C error handling in the C APIs, but it needs some work. Ideally every function would return an indication if there is an error or not, either by returning a negative number or returning null. If there's an error, we would always read the last error message and then throw a constructed error in the higher level language. The error string returned by c2pa_error is formatted to included an error name followed by a colon. The rest of the string contains the error message. The error name can be converted into a specific kind of C2paError in languages like Python.
I know there some inconsistencies and I've been trying to eliminate them. I want all possible null parameters checked and a consistent policy on setting the last error so that we never end up with an empty error state.

[tmathern]

Ok. In that case, I would suggest to merge that PR into your branch, and rework from there (I really don't want the 2 branches to diverge too much).

[gpeacock]

Ok, let's merge this and we can rework things in one place