Allow overriding label for values

[JeffersonBledsoe]

This PR introduces the concept of a 'display value' to change how a value will appear in an email or on a form. For example, a 'Single choice' field could have submitted values of ['A', 'B', 'C'], but are shown to the user as ['Option A', 'Value B', 'Option C'].

Mostly tested in production with the 'Yes/ No widget' in volto-form-block, but should work for other fields too!

Requires collective/volto-form-block#85 for frontend

[coveralls]

Pull Request Test Coverage Report for Build 7920161992

Details

• 0 of 93 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+3.5%) to 93.205%

---

Totals
Change from base Build 7919988301:	3.5%
Covered Lines:	727
Relevant Lines:	780

---

💛 - Coveralls

[JeffersonBledsoe]

While getting this up-to-date, I noticed we are now removing fields who's IDs don't exist on the form block definition (great!). This logic needs updating to account for custom_field_id being sent rather than the original field ID

[folix-01]

@JeffersonBledsoe Add some tests please

[folix-01]

@JeffersonBledsoe Add some tests please

Ah ok, exists already, just opened old version of this pr in some way :D

[JeffersonBledsoe]

@JeffersonBledsoe Add some tests please

Ah ok, exists already, just opened old version of this pr in some way :D

Haha, thanks for checking! 😄 I look forward to the feedback!

[JeffersonBledsoe]

@mamico @folix-01 Mind taking a look at this?

[mamico]

@JeffersonBledsoe thanks! looks good and useful for me, I will test them with a staging environment and come back shortly.

Just a question, if you already know, the changes here are useless, but also non-breaking, if you have the current Volto addon, is that right?

So, if I understand correctly, the dependency will be to have this released first and the frontend later?

[JeffersonBledsoe]

@mamico Sorry, I missed this GitHub notification!
The changes all seem to work fine with volto-form-block. I haven't tested with the latest as we're a little behind main and have customisations in what we deploy to production, but I can test it. Things will still work as expected on the frontend if this is released first but you simply won't be able to configure this feature. So yes it's non-breaking and the backend needs the release first.
The refactoring of the field handling logic shouldn't impact anything.