How should be the timeout of the socket be estimated in a stop-and-wait protocol over UDP? Can it be just any arbitrary integer multiple of the round-trip-time (RTT)?
Ideally, you want the timeout to be equal to the exact time it takes from the moment you've sent a packet, until the moment you receive the acknowledgement from the other party - this pretty much the RTT.
But it's almost impossible to know the exact ideal timeout in advance, so we have to guess. Let's consider what happens if we guess wrong.
If we use a timeout which happens to be lower than the actual RTT, we'll timeout before the ack had time to arrive. This is known as a premature timeout, and it's bad - we're re-transmitting a packet even though the transmission was successful.
If we use a timeout which happens to be higher than the actual RTT, it'll take us longer to identify and re-transmit a lost packet. This is also bad - we could have identified the lost packet earlier and re-transmitted it.
Now, about your question:

Can it be just any arbitrary integer multiple of the round-trip-time
  (RTT)?

First of all, the answer is yes. You could use any positive integer, from 1 to basically infinity. Moreover, you don't even have to use an integer, what's wrong with a multiplier of x2.5? 
But what's important is to understand is what would happen with different multipliers. If you pick a low multiplier such as 1, you'd run into quite a few premature timeouts. If you pick a large number, such as 100, you'd have many late timeout, which will cause your transmissions to halt for long periods of time.
Setting timeout in Stop-and-Wait protocol in UDP