Add planning final status fields and codelist

[duncandewhurst]

• Closes Planning final status codelist #1583
• Related to Date of final state change #1582

[duncandewhurst]

The spell-check failure is addressed by #1641

[odscjen]

My reading of #1582 and the associated CRM issue is that it's not just the planning final status date that's needed by also a tender.finalStatusDate

[duncandewhurst]

Ah, good spot. I shouldn't have marked #1582 as being closed by this PR. I figure it makes sense to do those other final status date fields when adding the new final status fields in #1160.

Alternatively, we could do all of the final status and final status date fields in this PR. @jpmckinney let me know what you prefer.

[jpmckinney]

My comment in #1583 was to close it "After #1160 and #1582". #1583 is more like a new feature, whereas #1160 is a major change (#1582 is also more like a new feature). The major change should lead, before related features are implemented.

I prefer to close #1160 on its own. #1582 and #1583 could potentially be combined.

[duncandewhurst]

Sounds good! I'll pause work on this PR and prepare a PR for #1160 (PR: #1648)

[jpmckinney]

@duncandewhurst This is now unblocked.

[duncandewhurst]

I think this is ready for review, unless I missed something.

[jpmckinney]

I aligned 'cancelled' with all other 'cancelled' in other codelists (basically, it's a decision by the buyer, always for the same potential reasons).

I also aligned 'unsuccesful' in terms of structure, and using a less specific example. A specific example, is e.g. a building application where residents might reject it.