Transmit doesn't properly check configured DRs for feasibility

[terrillmoore]

At least for EU-like regions, the following sequence causes undefined behavior:

1. join to a network that doesn't enable any 250 kHz or FSK channels (DR6 or DR7 in the LoRaWAN specs, EU868_DR_7B or EU868_DR_FSK in our code).
2. set the transmit datarate using LMIC_setDrTxpow(LORAWAN_DR6, 0).
3. send a message

The code will not discover that there's no suitable channel for this DR. The result will not be good, as the code will blindly transmit on the channel defined by LMIC.txChnl.

The LMIC must:

1. not transmit at a datarate that is not enabled in LMIC.channelDrMap
2. return an error if not able to transmit data
3. not assume that the conditions that obtained when the next channel was computed (at the end of a tx) still obtain on the next transmit -- the caller might have changed something, or we might be class b or class c, in which case the network can be telling us things dynamically.

The LMIC should:

1. allow the user to check whether a given datarate is currently feasible for transmit (over any channel). This is just an API that forms | / channelDrMap (in APL notation), or additional code that maintains a global drMap.
2. allow the user to use a higher datarate without committing to it (currently, once set, if it's not feasible, it's not clear what should be done; probably we should use the highest feasible DR).

Some of this is not region specific; the DR feasiblity APIs and changes in semantics of LMIC_setDrTxpos() are probably global.

[terrillmoore]

This was fixed by #416