Support forc build --json-abi-with-callpaths

[nedsalk]

From this rust-sdk issue:

Currently, type-paths are feature-gated behind the forc flag --json-abi-with-callpaths.
Once the TS SDK implements support for type paths, forc will make this behavior default.

Running forc build with the flag --json-abi-with-callpaths "outputs json abi with callpaths instead of names for struct and enums". We can take the sway program below as an example:

contract;

use std::address::Address;

struct CustomAddress {
    value: b256,
}

abi MyContract {
    fn std_address(address: Address) -> b256;
    fn custom_address(address: CustomAddress) -> b256;
}

Running forc build produces these types in the abi:

[
  {
    "typeId": 0,
    "type": "b256",
    "components": null,
    "typeParameters": null
  },
  {
    "typeId": 1,
    "type": "struct Address",
    "components": [
      {
        "name": "bits",
        "type": 0,
        "typeArguments": null
      }
    ],
    "typeParameters": null
  },
  {
    "typeId": 2,
    "type": "struct CustomAddress",
    "components": [
      {
        "name": "value",
        "type": 0,
        "typeArguments": null
      }
    ],
    "typeParameters": null
  }
]

Whereas building it with --json-abi-with-callpaths produces this:

[
  {
    "typeId": 0,
    "type": "b256",
    "components": null,
    "typeParameters": null
  },
  {
    "typeId": 1,
    "type": "struct CustomAddress",
    "components": [
      {
        "name": "value",
        "type": 0,
        "typeArguments": null
      }
    ],
    "typeParameters": null
  },
  {
    "typeId": 2,
    "type": "struct std::address::Address",
    "components": [
      {
        "name": "bits",
        "type": 0,
        "typeArguments": null
      }
    ],
    "typeParameters": null
  }
]

The second abi names the struct from the std library with its callpath. This is very beneficial because we can use it to differentiate between sway standard library constructs and custom constructs and custom-tailor our typegen and abi-coder for a better developer experience.

For example, the generated types and functions based on the first abi would be

export type AddressInput = { bits: string };
export type AddressOutput = AddressInput;
export type CustomAddressInput = { value: string };
export type CustomAddressOutput = CustomAddressInput;

export class MyProjectAbi extends Contract {
  functions: {
    custom_address: InvokeFunction<[address: CustomAddressInput], string>;
    std_address: InvokeFunction<[address: AddressInput], string>;
  };
}

Whereas what we could support with this flag is the following:

export type CustomAddressInput = { value: string };
export type CustomAddressOutput = CustomAddressInput;

export class MyProjectAbi extends Contract {
  functions: {
    custom_address: InvokeFunction<[address: CustomAddressInput], string>;
    std_address: InvokeFunction<[address: string], string>; // <--------------- Not object but string
  };
}

This way we can custom-tailor other std types like EvmAddress, Identity, ContractId, etc.

Our typegen currently doesn't support this build flag because it generates the corresponding types like this:

export type std::address::AddressInput = { bits: string };
export type std::address::AddressOutput = std::address::AddressInput;