Well remaining accounts at the end of the day is just an array of accounts, in anchor lingo context in aCpiContext you specify all the accounts defined in the context and it exposes a helper with_remaining_accounts that consumes CpiContext and returns another CpiContext with the remaining accounts.
If we glance at ToAccountinfos impl for CpiContext it calls accounts impl of to_account_infos and extends the vector with the accounts stored in its with_remaining_field and at the end adds the program id in question.
As far as solana is concerned , solana programs dont have the concept of remaining accounts, they take as input a slice of accounts and depend on the passing program/client/user to ensure the order is correct.
To answer your question , you must make sure the order of accounts you pass to solana::invoke if the recipient program is an anchor program ensure the accounts specified in its Instruction struct are specified first and then pass any remaining accounts you desire and in the end pass the program id, basically mimic what a CpiContext will do, but if you have access to the program crate you can construct a CpiContext from it and then use with_remaining_accounts to pass the additional accounts and bank on anchor to do the rest.
Given you have the idl, you can take a look at this issue : https://github.com/coral-xyz/anchor/pull/2857 which has added the declare_program! macro to generate an on-chain , dependency free module which you can use to interact with this third party program from your onchain program/smart contract.
PSA : the new declare_program feature is not yet released in the distributed anchor versions, you will have to build from source to use it , or you can use this other tool by lads at SaberHq on which the incumbent anchor feature is based on. :https://github.com/saber-hq/anchor-gen