BOLT #12: remove definitions around "raw invoices".

The specification wasn't fully fleshed out for these, so leave them
undefined.  We can always re-add them in future.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

12-offer-encoding.md

@@ -518,11 +518,8 @@ informative for the payer to know how the sender claims
 Invoices are a payment request, and when the payment is made, 
 it can be combined with the invoice to form a cryptographic receipt.
 
-The human-readable prefix for invoices is `lni`.  The recipient can send it in
-response to an `invoice_request` using the `onion_message` `invoice` field
-(in which case, it duplicates the fields including the compulsory
-`invreq_payer_id`), or can be produced spontanously (in which case, it has
-more limited fields, and in particular has no `invreq_payer_id`).
+The recipient sends an `invoice` in response to an `invoice_request` using
+the `onion_message` `invoice` field.
 
 1. `tlv_stream`: `invoice`
 2. types:
@@ -716,12 +713,7 @@ A reader of an invoice:
     - otherwise (invoice_request without an offer):
       - MAY reject the invoice if it cannot confirm that `invoice_node_id` is correct, out-of-band.
   - otherwise: (a invoice presented without being requested, eg. scanned by user):
-    - if `invreq_chain` is not present:
-       - MUST reject the invoice if bitcoin is not a supported chain.
-    - otherwise:
-       - MUST reject the invoice if `invreq_chain` is not a supported chain.
-    - MUST reject the invoice if `invreq_payer_id` is present.
-    - MUST reject the invoice if `offer_description` is not present.
+    - MAY choose to accept or reject the invoice.
   - MUST reject the invoice if `signature` is not a valid signature using `invoice_node_id` as described in [Signature Calculation](#signature-calculation).
   - SHOULD prefer to use earlier `invoice_paths` over later ones if it has no other reason for preference.
   - if `invoice_features` contains the MPP/compulsory bit:
@@ -774,6 +766,10 @@ request), the payer needs to ensure that the invoice is from the
 intended payment recipient.  This is the basis for the suggestion to
 confirm the invoice_node_id for this case.
 
+Raw invoices (not based on an invoice_request) are generally not
+supported, though an implementation is allowed to support them, and we
+may define the behavior in future.
+
 # Invoice Errors
 
 Informative errors can be returned in an onion message `invoice_error`