The rewrite of custom fields on the JavaScript side broke several

aspects of text-based fields, causing rendering glitches and bad data

stored in extra_data. The following issues were found:


The registered field ID was often being used instead of the JSON

   field name, preventing some fields from being looked up in any

   payloads.


Similarly, a <fieldID>RichText boolean was being looked up (and

   saved) for custom fields, instead of using the

<json_field_id>_text_type value.


These values were always being pulled out of extra_data, which

   resulted in corrupted displays, as we were requesting HTML renders of

   the values. raw_text_fields should have been used instead.


The new dirty handling wasn't noticing changes to the Enable Markdown

   checkbox, due to race conditions in calculation.


Fields now have mandatory jsonFieldName and jsonTextTypeFieldName

(for text fields) attributes, which are guaranteed to be set. These are

used or provided wherever we may be working with extra_data or

raw_text_fields.
setDraftField() and getDraftField() now assert for required values.

getDraftField() also now accepts some options for working with

raw_text_fields.
Value loading for fields has been centralized in a _loadValue()

function, preventing some copy/paste for non-trivial calls. Same with

loading rich text booleans for text fields.
Unit tests have been introduced for custom fields to check all the

various states, preventing regressions in the future.

All unit tests pass.
Tested loading and saving both plain text and Markdown text for

all forms of built-in text fields (Close Description, Draft Change

Description, Description, Testing Done) and custom text fields.

Ensured that initial loads of both text types work, that saving

works, and that saving twice in one page session works.