In the API when including multiple text types via ?include-text-types=,

custom text fields stored in extra_data are supposed to be returned

in an extra_data dictionary within the respective <type>_text_fields.

However, these custom text fields were not being serialized at all.
Within the serialize_object() function an empty dictionary,

all_text_types_extra_data, is established to hold any custom text data

and map it with the requisite extra include types.  This is passed to

_serialize_text_info() which is responsible for populating the dictionary.

However, there is a requirement in this lower level function that the

dictionary already has keys corresponding to the requisite types.  Since the

dictionary is empty, and thus does not satisfy this condition, no population

occurs.
The solution is to re-initialize all_text_types_extra_data to contain the

requisite types as keys upon encountering the first custom text field that

supports markdown.  It is critical to perform this step after this initial

encounter, rather than at original initialization time, so as not to end up

with an empty extra_data dictionary under <type>_text_fields in the case

where no custom text fields actually support markdown.
Original and modified JSON output from a sample GET request

(http://127.0.0.1:8080/api/review-requests/83/?api_format=json&force-text-type=html&include-text-types=raw)

is attached to illustrate the effects of the change.  Notice the addition of

the "extra_data" field under "raw_text_fields".

Added new tests to exercise this functionality.  Fundamentally these are

concerned with ensuring the extra_data dictionary appears within the respective

<type>_text_fields.  But, I also took this opportunity to test some other items

that didn't necessarily seem to be covered by other tests.  These include:

Custom fields that both do and don't enable/support markdown.
Use of field name "text" for custom fields to cover special case.
Multiple include-text-types types via CSV list.