Feat: steal core NFTs and collections

[IVSOP]

Adds feature described in #391, allowing changing ownership of a core NFT and authority of a core collection, through the new surfnet_stealCore endpoint.

Example request, stealing this random core NFT

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "surfnet_stealCore",
  "params": [
    "2mNhQ5GHcn2y4CtR32LSKvhNzRumeVH1PMkFdACwqtNz",
    "<key of the new owner>"
  ]
}

[MicaiahReid]

Thanks for the PR, @IVSOP! This helps me understand the feature better.

Thoughts @lgalabru and @IVSOP on this PR as-is vs two cheatcodes:

• surfnet_setMplCollection - sets data according to this struct https://docs.rs/mpl-core/latest/mpl_core/accounts/struct.BaseCollectionV1.html
• surfnet_setMplAsset - sets data according to this struct https://docs.rs/mpl-core/latest/mpl_core/accounts/struct.BaseAssetV1.html

This would make each endpoint more "full-featured", like surfnet_setAccount/surfnet_setTokenAccount

[IVSOP]

I didn't split the endpoint because the logic is the exact same (just write a key into data[1..33]). If you want to set the full data, then I think having two separate cheatcodes would be cleaner. as the arguments and logic would be slightly different.
In the future, if you want to also change the plugin information, then it would make even more sense to split into two cheatcodes, so this is future proofing as well

[lgalabru]

What would be the next steps on this PR @IVSOP @MicaiahReid ?

[IVSOP]

I've changed the endpoint from stealCore to updateCoreAsset and allowed changing every part of the header, and optionally deleting all the plugins.
I had to drag in the mpl-core crate because it was too cumbersome to replicate the functionalities and types without relying on it. However, I had many challenges with dependency conflicts and with the fact that its autogenerated client interface doesn't expose all of the functionality I need / exposes it in a way that is very hard to work with.
I ended up forking the crate and adding very minimal functionality so I could avoid the dependency conflicts. The code for this endpoint ended up being very large and might be hard to follow, due to the unergonomic data the crate returns, and having to manually implement serialization and deserialization of the plugins.

In short, the plugins use a byte offset system. An offset of N means some plugin is located at bytes[N..M]. If we change the owner in the header, its length does not change as pubkeys have a static size. However, if any of the strings change, we have to re-serialize the plugins so that they all have the correct offsets.

I'd like to hear your thoughts before I implement a similar endpoint for core collections and not just assets.
New example:

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "surfnet_updateCoreAsset",
    "params": [
      "2mNhQ5GHcn2y4CtR32LSKvhNzRumeVH1PMkFdACwqtNz",
      {
        "owner": "<<<some new owner pubkey>>>",
        "name": "some new name",
      }
    ]
  }

You can test this for yourself using the NFT viewer I provided in the top message and using the localhost mode.