fix: recursive idl gen

[guibescos]

There's a bug in the logic for adding external types from other crates into the idl.

The way it works is a macro that :

• first checks use statements to see which crate the type is imported from'
• looks for the Cargo.lock of the project
• then finds the name and version of the crate in Cargo.lock
• then looks for the type definition in the cargo registry for that crate locally

The bug I'm trying to fix appears in a recursive situation where a program A imports a type from crate B which uses a type from crate C.
When the macro gets expanded in crate B, it is incapable of finding the Cargo.lock of the project and panics (this is because at that point the working directory is the ~/.cargo/registry and not the anchor workspace ).

I propose to update the code so Cargo.lock is searched from the program path.

Here's a reproducible example:
https://github.com/diyahir/minimal-pyth-version-error

• Program is tic_tac_toe, it imports the Anchor type PriceUpdateV2 from Crate B
• Crate B is pyth-solana-receiver-sdk, it imports the Anchor typePriceFeedMessage from Crate C.
• Crate C is pythnet-sdk

[vercel]

@guibescos is attempting to deploy a commit to the coral-xyz Team on Vercel.

A member of the Team first needs to authorize it.

[acheroncrypto]

Thanks for the fix!

External type resolution by looking at the source code is not even necessary for external Anchor types, but unfortunately, we don't have a direct way of deciding if the type is an Anchor type or not.

Before we merge, could you note this fix in the CHANGELOG?

[guibescos]

Addressed the comments

[acheroncrypto]

Thank you!