Remove Lumina Pinning

[KazWolfe]

Currently, Dalamud blocks plugins from loading in their own version of Lumina.

This behavior has caused problems for a couple plugins that needed to fork or modify things against test or tweaked versions of Lumina, and has requested to be removed. At present this feature is slated for removal in API 10, with this Issue serving as a reminder that we need to give it consideration and actually do it.

[KazWolfe]

As a personal note, I'm still not particularly in support of doing this as this feels like a massive footgun just waiting to happen.

While it is strange for us to pin Lumina (and only Lumina) like this, raw Lumina types are also part of our exposed API surface in many places. Any plugin bringing their own version of Lumina will have headaches with IDataManager and various properties scattered all over our public API surface. Plugins shipping their own Lumina will not be able to use any of these API surfaces, and it's not particularly clear at a glance what would or wouldn't be broken especially to a novice developer.

Given that we have had plugins accidentally forget <Private>false</Private> in their csproj files before or were otherwise shipping Lumina (sometimes intentionally?), it does seem like problems related to this are actually possible.

If we decide that we do want to go forward with this, I'd like to request that this be heavily documented somewhere easily accessible to developers so that everyone is well aware of this choice and how to resolve this problem if one inadvertently ships their own Lumina. I'm not sure I'd go as far as adding a manifest flag for AllowCustomLumina, but I'm not strictly opposed to that either...

[KazWolfe]

Alright, upon further consideration here. Seeing that API 10 is just around the corner, I think this would be a good thing to bring in.

Let's define this such that we will allow loading a custom Lumina if a manifest field is set to a truthy value. We can then create documentation around this to indicate that multiple/many APIs provided by Dalamud will no longer function properly. We can also likely add a warning to our local plugin system indicating that this is enabled.

I think this satisfies any concerns about API safety while still allowing developers control over their dependencies. So long as the behavior is known and explicitly opt-in, I can't see many problems arising from this.

---

For the manifest field, I think it'd make sense to define a new K/V field:

...
FeatureGates:
  AllowCustomCoreDependencies: true
  SomeOtherFeatureGate: true
  AnotherThing: true
...

We can expand on this to add extra features later on (e.g. the ability to opt in to [Experimental] attributes on Plogon builds).

If anyone wants to PR this to the API 10 branch, let me know and I'll assign you to this Issue.

[KazWolfe]

Closing until such time as this becomes necessary again and someone wants to work on it.