Every single signature contains an R and s value. Those two values are what define a signature. P2SH scriptSigs generally do have signatures but their locations are dependent on the script being executed. You essentially need a script interpreter to find them. There are scripts that don't have signatures, but those are few and far between. Z can be calculated for any input independent of signatures, although there are actually multiple possible values and getting the right one for verifying a signature depends on the sighash type found at the end of the signature.
There is no single R, s, and Z values for a transaction. Each signature has a R and s value. There are multiple possible Z values for a signature, depending on the sighash type. Each input also has a different Z values regardless of sighash type as each input requires different data to be hashed.
I don't know of any tool that computes these automatically for every signature, but it's pretty easy to do it yourself. Each ECDSA signatures is a DER encoded signature with the ASN.1 syntax
r ECPoint,
s INTEGER
}
Within a scriptSig or scriptWitness, signatures are pretty easy to spot. Because DER encoding follows some pretty specific rules, the beginning of each signature is fairly distinct. Each signature begins with either 30440220 or 3045022100 and is either 71 or 72 bytes long. You can then decode the signature as just described to get the R and s values.
Z is the hash of the message being signed. It is specifically the double sha256 of the message. For non-segwit inputs, the sighash algorithm is described in the stack exchange thread linked by HeRetiK. For segwit inputs, it is described by BIP 143