Add support for querying current max payload size

[terrillmoore]

With ABP in the US, max payload may be 11 bytes. The app needs to know this, and adapt.

ArduinoLoRaWAN::SendBuffer() doesn't return an unambiguous error for packet-size overflow (it just returns a bool). After a failed SendBuffer(), we need a few things:

• a way to find out whether the failure was due to buffer overflow due to max packet size constraints
• a way to find out the current max packet size
• perhaps, a way to find out the max packet size in view of current pending MAC uplink requests (certainly, we should design the API to support this, even if we don't want to support it right now).

[terrillmoore]

This is poorly thought through because it doesn't address the ADR negotiation. This probably has to be in LMIC. The app should tell the MAC it's minimum packet size. The MAC should then use this in two ways:

1. to control the minimum it will accept in ADR and LinkTracking discussions with the core network. If core network wants device to go to SF10, but regs and app require SF9, then device should say "no" to the ADR request. (This lets the network know that the device can't accept the parameters, so it can do things like enabling replication instead.)

2. to control its choice of uplink parameters when actually transmitting.

Should do an architectural study on this, as we need to test use cases against proposed implementation.

[terrillmoore]

After the certification work and experience with apps, this is clearly the wrong question to ask because there is no well-defined answer in LoRaWAN as to the "maximum size of next uplink". Closing this.