What is customizable in ECDSA signature and verification? Let's say I make a signing and verification ECDSA modules. Signing module receives plain message and outputs signed message. Verification module takes signed message and checks consistency.

Theoretically which things should be known to both modules:


Padding scheme for message
Hashing function
Scheme for combining message and signature


Something else?

Additionally signing module should know the private key, and verification module the public key. How these keys were generated (parameters used, such as curve used) is irrelevant to signing and verification modules?
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.

Something else?

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...