Is clock wire always needed in synchronous serial?
So, from wikipedia:
Synchronous communication requires that the clocks in the transmitting and receiving devices are synchronized – running at the same rate – so the receiver can sample the signal at the same time intervals used by the transmitter.
So, what you need is synchronous clocks, not necessarily a clock signal.
If not, how do we synchronize?
There's plenty of ways to keep synchronization. In fact, synchronization is among the most diverse things you'll find in digital communication schemes – so, I really can't list all the things systems do to synchronize. There's just too many different approaches, and a lot of them really only make sense in the very narrow use case of a specific system.
Instead, let's talk about a few typical, or extreme things.
For lower rate things, simply having a good common time base works – whether it's something you've got from GPS, or something you got by having been equipped with a quartz crystal and a battery.
Often, clock synchronization is done based on the signal's shape you're receiving. Remember that no real-world signal has ever infinitely steep edges, because that would require infinite bandwidth (and that would require infinite power. Also, real-world systems are practically always low-pass systems).
So, instead, if you know about that problem, you start shaping your pulses, e.g. instead of trying to send -1 V for a symbol period followed by +1 V for a symbol period, you start smoothing out with a filter. You do that in a controlled way! (You might want to google "eye diagram" to see what that looks like for high-speed serial buses.)
Now, your receiver has something to work with: whenever you have a symbol switch (and that should, in our 1 symbol = 1 bit scheme practically be as common as not switching, so pretty often), you get a nice slope between your last and your next symbol. If you average a bit, you'll see that you only get a nice maximum or minimum, i.e. zero derivative, when you look at the signal at the right point in time. If you're a bit too early (or too late), you'll notice by always being a bit on the slope instead of "top of the hill", so you can correct for that.
A system that finds the correct times to evaluate the signal from the signal itself is called timing recovery. What I described above is one of a lot of methods of dealing with that – others involve preambles, feedback, simply testing multiple delays, …
That's half of what you need to be synchronous. The other half is having the right clock frequency. Such problems are very often solved by means of removing the actual data from the transmission (in our +1V/-1V example above, simply square the voltage), and then looking for periodicities and using these, e.g. in a PLL (like your 1980's car radio proudly boasted a "PLL" label, the Phase-Locked Loop is just a way to train a local oscillator based on the average speed of the transmitter's oscillator). Other methods involve preambling with a clean tone, superimposing a tone at a frequency that you can remove with a filter so it doesn't mess with your data signal, autocorrelation methods, and many, many more.
So, as you can see, many different ways to deal with that problem, and in the world of baseband communications, you use different things (e.g. Manchester coding) than in the RF comms world (e.g. Schmidl&Cox sync for OFDM).
When we say asynchronous, does it always mean we use start and stop bits?
No. It's just a convenient way of telling your receiver that transmission starts (stops) now. Depending on the application, this might be something you want, or something you don't need.
If not, how do we synchronize?
Not at all, that's the point: your receiver just runs and doesn't get to recover the "beat" of your transmitter from a clock signal or the data signal it's getting. The assumption is that this just works, because there's enough "leeway" in the signal.
For example, if I send a bit as symbols of +1 or -1 V, with a symbol rate of 1 sym/minute, even you as human won't need access to my clock at all – you just start looking at the voltage I send. Chances that you're looking exactly at the point where I switch symbols are very low. Chances that your wristwatch is so inaccurate that you'll lose (or gain) more than a minute relative to my wristwatch within the say 16 bits I want to send are so low that you can live with that.