In SSL (and TLS) when an HTTPS-enabled Web server is first contacted by a client (most typically a browser) it responds to the client with a "Server Hello" message, swiftly followed by a "Certificate" message. Both of these messages appear, rather handily, in the network trace that you've included.
The "Server Hello" message isn't particularly relevant to your question here, though, as it implements the mechanism by which the server tells the client which version of the SSL or TLS protocol it's decided to use, and also which cipher suite it's decided to use.
The server's "Certificate" message is rather more interesting. This message consists of a sequence of one or more certificates. Your network trace shows that your particular server has included three certificates in its "Certificates" message.
The first certificate in the sequence is always the server's own certificate. If you open up that first certificate in your network trace record (i.e. the certificate that's 1406 bytes long) it will almost certainly show the server's own DNS name, as the value of the CN (or Common Name) attribute. There is a pile of other stuff in that first certificate too (e.g. the server certificate's Start and Expiry dates and times, and its public key). Another item that's relevant to your question here is the server certificate's Issuer field, which contains the identity of the CA (Certificate Authority) certificate which issued the server's own certificate.
This is where certificate chains come into play (as described in the link given earlier by Steffen Ulrich). A Web server's certificate is almost invariably issued by a higher-level certificate (a CA certificate), and that higher-level CA certificate is often itself issued by a yet-higher-level CA certificate. And so on - but not ad infinitum! There has to be an end to the chain of higher-level CA certificates somewhere, and it does indeed always end, at a so-called "Root" CA certificate. A Root CA certificate is not issued by any higher-level CA certificate - so the buck finally stops there.
The long and the short of it is that your network trace shows that your server has sent the client a chain of three certificates. The first certificate will be the server's own certificate, as already mentioned. The second certificate will be the CA certificate that issued your server's certificate. And the third certificate will be the Root CA certificate, that issued the second certificate.
So your server's "Certificate" message contains the complete chain, from your server's own certificate, up through the Intermediate CA certificate, and finally up again to the Root CA certificate.
When this little lot arrives at the client, the client now has everything it needs to check, and prove, the identity of your server. Amongst other things, it's very important that the client is able to discover whether the Root CA certificate is one that it trusts. If the Root CA certificate that (ultimately) issued your server's certificate is not actually trusted by the client, then it will complain (typically by telling the user that the server's certificate is not trusted, and then asking the user whether he or she wants to go ahead and continue to communicate with the server anyway).
It's essential that the server must always send the client its own certificate (so that the client can check that the server's own identity is as expected). So there will always be at least one certificate in the server's "Certificate" message. However, it's not absolutely essential for the server to send the other (higher-level) CA certificates as well (because the client could in principle resort to other means to discover the rest of the certificate chain). But it sure helps the client if the server does send them all. Which (finally) explains why you're seeing your server sending multiple certificates.
On the final part of your question (the OpenSSL, Apache, and GnuTLS servers) I guess it probably depends on exactly how you configure them. Unfortunately I'm not familiar enough with them myself to know how you'd do that, in each case. But I'd recommend that where possible, you should aim for those servers to always return the complete certificate chain to the client, in much the same way that's shown in your network trace.
There's an awful lot more that could be said about SSL and TLS - but this certainly isn't the place! If you want to find out more from a real expert, I can recommend Eric Rescorla's fine (though now rather dated) book "SSL and TLS - Designing and Building Secure Systems", ISBN 0-201-61598-3, published in 2000. Hopefully though, you'll now have a bit more traction on your question anyway.