Fix charset conversion for concatenated deliver_sm parts

[cl77]

Problem

Parts of concatenated messages (with UDH) are written to the deliver_sm PDU using ksmppd's internal UTF-8 text representation, while single-part messages are correctly re-encoded to GSM 03.38 first.

In smpp_pdu_msg_to_pdu() (smpp/libsmpp/smpp_pdu_util.c), the loop over the parts produced by sms_split() has two branches:

• no UDH (single-part): short_message is duplicated and then converted via charset_utf8_to_gsm() / alt-charset when data_coding is 0 - correct.
• with UDH (concatenated): short_message = octstr_cat(udhdata, msgdata) with no charset conversion at all - the raw UTF-8 bytes leak into the PDU.

As a result, ESMEs receive concatenated text messages announced with data_coding = 0 (GSM default alphabet) whose payload is actually UTF-8. Example: the Euro sign arrives as e2 82 ac instead of the GSM7 escape sequence 1b 65. Single-part messages containing the same characters arrive correctly, which makes the behaviour inconsistent and impossible for the receiving ESME to interpret reliably.

Fix

Apply the same re-encoding logic already used for single-part messages to the UDH branch, before the UDH is prepended:

• data_coding & 0xF0 or data_coding == 0 without alt_charset: convert UTF-8 to GSM 03.38
• data_coding == 0 with alt_charset: convert to the configured alternative charset

Only DC_7BIT text parts are converted; binary (8-bit) and UCS-2 parts are unaffected (UCS-2 already worked correctly since the internal representation is UCS-2BE for those).

Verification

Test harness calling smpp_pdu_msg_to_pdu() with a 183-character DC_7BIT message containing a Euro sign (split into 2 parts, data_coding = 0):

Before (part 0, after 6-byte concat UDH):

data: 05 00 03 00 02 01 e2 82 ac 20 4c 6f 72 65 6d ...   (UTF-8 Euro)

After:

data: 05 00 03 00 02 01 1b 65 20 4c 6f 72 65 6d ...      (GSM7 Euro)

Single-part messages, UCS-2 and binary messages are unchanged.