Don't flush the CC2538 RF RX FIFO unconditionally

After reading a frame, `read()` checks the status of the RX FIFO:

* If an overflow is detected, the FIFO gets flushed
* If there are more frames in the FIFO, the `cc2538_rf_process` will get polled again in order to read out the next frame.

#1550 changed `read()`, which now performs the above check for non-poll mode, but it then flushes the FIFO unconditionally. Therefore, if there are two or more frames in the FIFO, they will get flushed before the `cc2538_rf_process` has had a chance to read them out. This results in missed frames.

Reproducing this is trivial: Build a CC2538 sniffer and see how it will never show you .15.4 ACK frames. ACK reception completes while `read()` is still streaming the previous captured frame to the host. Upon completion, the FIFO will get flushed and the ACK will get lost.

This pull proposes removing the unconditional flush and reverting to the original logic for non-TSCH operation.

Pinging @thomas-ha here for input regarding poll mode.

This pull sits on top of #1778

cpu/cc2538/dev/cc2538-rf.c

@@ -823,8 +823,6 @@ read(void *buf, unsigned short bufsize)
     }
   }
 
-  CC2538_RF_CSP_ISFLUSHRX();
-
   return len;
 }
 /*---------------------------------------------------------------------------*/