SPI or I2C: which to use for a longish bus

As others have said, SPI and I2C can be used over long distances as long as the pull-up resistors, clock frequencies and so on.

The main alternatives (which will give better noise immunity) are RS485 and CAN. Both of these use differential lines in order to minimise noise issues and are better suited to this length of data transmission than I2C or SPI. However, I don't think many (any?) AVRs come with built-in CAN peripherals, which make CAN use much easier.

I would say that the most important thing to consider when picking a bus is to ensure that the protocol you use for communicating between devices includes a CRC or equivalent so that you can determine whether a message has been received correctly (CAN has this as part of the packet). Considering this, it's also useful to have an ACK/NACK type response as part of the protocol so that a corrupted message can be re-transmitted.

Several feet shouldn't be problematic, just use twisted wires if you can. SPI is much easier to buffer (if you need to) than I2C since SPI signals are all unidirectional, whereas I2C's signals are on shared lines.

can the AVR microcontrollers handle I2C and SPI slave modes as well as master modes? (you'd need both)

For I2C over long distances you might want to seek out some "I2C bus repeater" solutions. Keep in mind that any maximum distance you might find for I2C or SPI communication is mostly referring to the total bus distance and not the to distance between two nodes in a bus.

You might want to look into RS485 for these kinds of problems. It's a serial bus protocol which communicates over differential lines, so when using twisted wires, the chances of noise are minimized. Very long distances can be reached this way. The downside would be that you would need an extra RS485 encoder IC (like a MAX485 ,not very expensive) in your circuit.