Read the GSM 03.38 message class where the spec puts it (#95)

* Regression tests for the GSM 03.38 message class behind sms.flash

* Read the GSM 03.38 message class where the spec puts it, and refuse a flash message no alphabet can carry

* Keep the code span in the message-class decision on one line

* Stop offering the flash message class as an alphabet, and check the encoding option by name

* Settle every refusable send option in one check, and record what the review left open

* Say what the flash refusal and the encoding option actually do

* Keep the README off the alphabet whose long messages do not fit

interop-tests/findings/02-smppsim.md

@@ -60,6 +60,10 @@ tests passing, `malformed: 0`, `expert errors: 0` in both.
 | C17 (encodings over loopback) | pass | `smppsim - C17 …`, 5 sub-tests: Latin-1, UCS-2, flash (0x10), raw 0xF0 (not flash), raw UDH+8-bit-binary |
 | C18 (`smppsim-outbind`) | pass (record, not judge) | `smppsim-outbind - C18 …`; see below for the wire facts |
 
+C17's `raw 0xF0 (not flash)` recorded a `@larvit/smpp` defect, fixed in
+[#95](https://github.com/larvit/larvitsmpp/pull/95): 0xF0 is GSM 03.38 message class 0, so it reads
+as flash now.
+
 ## Defects in @larvit/smpp
 
 ### A delivery receipt's `data_coding` is trusted to decode its body, even though the spec makes the receipt a fixed text format