fix(sema): reject address.transfer / address.send on Soroban target

[gabrielrondon]

Summary

Soroban contracts do not have a native value-transfer model: balances move through the Stellar Asset Contract (SAC) or the token interface, not the contract runtime. Compiling <payable>.transfer(...) or <payable>.send(...) for --target soroban was reaching codegen and panicking at src/emit/instructions.rs:989 ("Found IntValue") while lowering Instr::ValueTransfer.

This PR mirrors the existing Solana guard at src/sema/expression/function_call.rs:1295 and rejects both methods at sema time on the Soroban target with a Soroban-specific diagnostic pointing the user toward SAC / the token interface.

Fixes #1909.

MRE (from #1909)

pragma solidity ^0.8.20;
contract C {
    function run() external payable {
        payable(address(this)).transfer(uint256(0));
    }
}

Before: solang compile --target soroban mre.sol panics at inkwell-0.4.0/src/values/enums.rs:278: Found IntValue(...).
After: rejected at sema with a clear diagnostic.

Test plan

• CI green on cargo test --features soroban
• New tests address_transfer_is_rejected_on_soroban and address_send_is_rejected_on_soroban pass
• No regressions in existing Soroban / Solana / Polkadot / EVM suites

Local validation: cargo check --tests --features soroban is clean. Full test run was not exercised locally because the macOS + LLVM 16 link path is fiddly; leaving the heavy lifting to CI.