predecessor_account_id is not surfaced

[amgando]

unless i'm misunderstanding something, it seems like predecessor_account_id can be easily surfaced into the context object exposed by near-runtime-ts

https://github.com/nearprotocol/near-runtime-ts/blob/4d7247f060deb63bf9aa7a287cb37c28609ccd7e/assembly/runtime_api.ts#L28-L29

but it is not https://github.com/nearprotocol/near-runtime-ts/blob/master/assembly/contract.ts

just happened to wonder about this specific method after reading through the Rust contract that implements the open web concept here: https://github.com/nearprotocol/near-bindgen/pull/66/

pub fn post_message(&mut self, app_id: AppId, message: Message) {
    verify_app_id(&app_id);
    self.verify_app_active(&app_id);
    let mut q = self.messages.get(&app_id).unwrap_or_else(|| {
        let mut vec_id = Vec::with_capacity(app_id.len() + 4);
        vec_id.extend_from_slice(b":m:");
        vec_id.extend_from_slice(app_id.as_bytes());
        vec_id.push(b':');
        Vector::new(vec_id)
    });
    q.push(&WrappedMessage {
        sender: env::predecessor_account_id(),  /// <-- HERE it is
        message,
        time: env::block_timestamp(),
    });
    self.messages.insert(&app_id, &q);
}

if what i've written above makes sense, then more generally, it seems like we could use a test that simply checks for parity between the namespace runtime_api and some implementation in near-runtime-ts. if a matching method is not found we can at least flag it as a warning or create an issue on the repo but not sure what makes sense here