Theoretically which things should be known to both modules:
- Padding scheme for message
As mentioned in the comments, the 'padding scheme' for ECDSA is either fixed or arguably nonexistent. You take the hash value, zero extend it if it's smaller than the group size, you take it modulo $q$ if it's bigger than the group size, and then fit that integer into the ECDSA equations.
- Hashing function
Yes, bare ECDSA signatures and public keys have no way of indicating what hash function is used. IMHO, it should be listed in the public key; it isn't (at least in my experience)
- Scheme for combining message and signature
Well, you appear to be under the impression that we always attach the signature to the message. Sometimes this is true, as in PGP. However sometimes this isn't true at all, for example, if we are using signatures to authenticate IKE; there, the value we sign is actually derived from the contents of a previous packet, hence we can't say that the message and the signature are combined at all.
What I've seen in practice is that we separate out the protocol level stuff (how are messages and signatures transported; there are a lot of varients used in practice) and the crypto stuff (how to do ECDSA); for example, on the verification side, there is some upper layer that somehow obtains the message and the signature, and then presents them both to the verifier.
Apart from the public and private keys that you mentioned:
The actual curve being used; that is far from irrelevant to the crypto module.
The format of the signature; I've seen two variants; one is to just paste the $r$ and $s$ integers together (using a fixed length for both); the other is to ASN.1 encode it as a sequence of the two integers. Now, it's possible that the protocol-level logic that I mentioned before would standardize that...