- let's say I take key length of 16 bytes. Does it mean that according to wiki I must pad the key with zeros from right up to 512 bits? (block length of SHA1)
Yes.
- opad must be a 512 bit value, like: 0x5c5c5c…5c5c....5c (512 bits)?
Yes.
- ipad similarly: 0x363636…3636 (512 bits long)
Yes.
- what to do with m if its length is not 512 bits?
This should not be relevant for the HMAC implementation itself, since the hash function is the cryptographic primitive responsible for effectively processing the message (of arbitrary length).
- what is the recommended length of actual key? and recommendation for key generation?
Before using it, HMAC will pad the provided key material with 0's until it reaches the block size. The size (and the quality!) of this key material depends on how much security your implementation is targeting. Note that RFC2104 "strongly discourages" the usage of keys of shorter length than the hash output (see comment from otus), which for SHA-1 would be 160 bits. As SEJPM mentioned in his comment to the question, the key can be either generated at random or pre-shared/derived from a common secret (see Diffie-Hellman).
is it bad idea to implement HMAC myself, if I have implementation of SHA1?
It might be a good exercise if you want to get familiar with cryptography implementation details. However if you need an HMAC implementation in the scope of a project for example, you may prefer to use an extensively tested and validated implementation (e.g., open source cryptography libraries).