Draft: Propose a DBus API for SMS parts

This merge request is related to #458. The goal is to expose SMS parts in the DBus API to achieve two things:

• allow applications to show already received parts of an incoming SMS (that takes long to come)
• allow applications to remove handled sms parts from the modem, to free up slots so other parts can be received. This let us handle (very) long messages that don't fit in the available modem slots.

As suggested by @aleksm, I put together a draft specification to expose sms parts. Two designs were envisioned:

1. one in which we would represent an incomplete SMS through an IncompleteSMS object. This objects would expose an array of already received parts and a method to delete parts from the modem. This incomplete SMS object would disappear as soon as a proper Sms object is created
2. one in which we would represent parts themselves

Here, I went for the second design, which, after reflection, seems cleaner to me.

With the first design, one would have to subscribe to the PropertiesChanged DBus signal and watch for modifications on the field containing the array of parts, or an hypothetical field containing the number of already received parts. It is also unclear to me which would be the best way to represent a not yet received part in the array. An empty string would probably do, but that does not seem very clean and clear. The application would need to go through this array and apply some diffing to discover new parts. the IncompleteSms object itself does not feel very "canonical" either, as opposed to a clean Sms object and clean "Sms part" objects. This API, while certainly pretty simple to understand, seems a bit complicated to use overall. However, I'm not fixed on this position and can propose a design for something like that if deemed better in the end.

In the second design, applications would watch for new SmsPart objects to appear. They will be able to retrieve data or text of a part, as well as other pieces of information on the part and the related SMS (including its index), as well as delete these parts from the modem. These objects are, as far as I understand, immutable.

To build the SmsPart model, I've copy pasted Sms and removed methods and properties I could not make sense of for an SMS part:

• Send: one would probably not send an SMS part being received
• Store: same idea, one would not store an SMS part being received
• State: this is an MMSmsState value. The state of an received SMS part is probably always… "received". However, it might make sense to have a state property for the future?
• MessageReference: this was a reference to the last PDU related to the SMS, seems irrelevant here.
• DeliveryReportRequest: does not seem to apply to a single part that was received?
• DeliveryState: same?

Now, I have three questions:

1. should this new object be called Pdu instead of SmsPart?
2. there are some fields common with Sms. I figured this duplication allowed applications to access this information without requesting the Sms object itself. But we might want to remove these duplicated fields field (keep the timestamps though).
3. What would be a good name for the Count field?

Thoughts?

That's the first DBus specification I work on and I haven't used DBUS for very long neither, so I fully expect this specification to have some flaws due to my lack of experience.