Tor's integrity verification system?
No.  What this means is that they concatenate all of this data and then SHA1-hash the concatenation.  There's no xor-ing of digests or anything like that.

The reason it's described this way is because many hashing APIs allow you to specify the data in a streaming fashion: you can specify the first few bytes of the message to be hashed, then you can specify a few more bytes (which will effectively be appended to the previous parts), then some more, and so on; eventually you tell the API that you are done and please return the hash.  You can think of the API as storing all of the data you passed to it, concatenating it, and hashing it all at the end.  However, for better performance, the API doesn't actually need to store all of that data: because of the way that SHA1 works internally, it can hash the data on the fly and avoid the need to store so much.  Anyway, the wording used to describe what is to be hashed is probably an artifact that mirrors the structure of the API for many SHA1 implementations.

This helps defend against man-in-the-middle attacks.  If both endpoints have the same SHA1 hash, then they must be using exactly the same data.  If a man-in-the-middle tries to modify any of this data while it is in transit, then the two endpoints will have different inputs to SHA1, so they will end up with different SHA1 digests.  Depending upon how the rest of the protocol is constructed, that may provide an opportunity to detect the man-in-the-middle.