Workfile api: Support project name

[iLLiCiTiT]

Changelog Description

Allow to pass in project name to workfile api methods.

Additional info

This is unfortunate, but there might be hosts where a single session can work with workfiles from different projects and context changes in workfiles api do not handle that at all.

All the methods where context is important now can expect project name in arguments.

Fixed bug in copy_workfile_to_context which did not handle missing prepared_data.

This was a quick made PR without full validation. This needs revisit and validate if it makes sense for all the affected methods to allow that. Also there might be hosts that do override some of the methods, in that case we might need to handle that.

Testing notes:

Validate code changes. Technically nothing should change at this moment and everything should work as it did before in all hosts. It it possible to open/save/copy/copy from representation workfiles.

Resolves #1948

[BigRoy]

I think we are not prepared for this. Live switching project context brings much more issues than this anticipates.

• It may have a different per project bundle.
• A very different suite of enabled applications, or tools and plug-ins.
• It may live at very different roots, etc. etc.

I understand certain DCCs may not be opened more than once, etc. but I feel like nothing we're doing in practice prepares for what this needs to be somewhat reliable and provide expected results in a production scenario. Until we do, I think the only reasonable approach is to handle this with a big line of red tape guarding the user.

Before we make the decision that this is remotely a reasonable way forward that needs tackling, let's discuss first - which DCCs, what doesn't work, what do we expect to work, etc. and make sure that we can actually make this work reliably etc.

So let's start of with a clear goal and a ticket describing what the end result is that we're after and why.