Introduce IAsyncDalamudPlugin to tidy up plugin lifecycle

[goaaats]

• Introduces IAsyncDalamudPlugin to tidy up plugin lifecycle
• Makes sure that calling UnloadAsync() or LoadAsync() don't block the main thread unnecessarily

TODO: LoadSync plugins and LoadRequiredState - does this "just work"? Should investigate before obsoleting old interface

[KazWolfe]

What's the intent for plugin lifecycle, then? I'd assume it's ctor, LoadAsync, , UnloadAsync, Dispose? In this case, this would also mean that the plugin's ctor would also be called in a random thread, yes? I'd like to see a broad list of things we'd want in the ctor vs LoadAsync in either case.

If so, I'm not certain we need to create a new interface for this. Would it be sensible to just place these new methods into IDalamudPlugin and assign a default implementation to them until we're ready to force people to do more async work?

[goaaats]

LoadAsync is really just for convenience. People have asked for it and there's no reason not to have it. The main reason for the new interface is implementing IAsyncDisposable instead and forcing people to rethink their disposal scheme.

[KazWolfe]

LoadAsync is really just for convenience. People have asked for it and there's no reason not to have it.

Would still be good to document when and why it should be used I think. I agree it's useful to have, but having two entrypoints can be a bit confusing alone.

The main reason for the new interface is implementing IAsyncDisposable instead and forcing people to rethink their disposal scheme.

Point taken. I'd ask we plan to refactor IAsyncDalamudPlugin back to just IDalamudPlugin in the future then, since the Async descriptor would become redundant if we're pushing everyone into async territory.

[Critical-Impact]

Is there a risk that a plugin fails to complete it's DisposeAsync in a timely manner(or never completes) and if that happens should we have a timeout? (Apologies if there is one, I had a look through and I couldn't see one)