[#2638] Implement choice of zaken notification channel

[pi-sigma]

• User can choose the channel for case notifications (post + digital or digital only) when registering
• User can edit the channel for case notifications (post + digital or digital only) in their profile
• Staff users can enable/disable the choice of notification channel via the admin

The default is post + digital.

As discussed, this is an MVP; styling of the radio boxes needs touch up to conform with design.

Taiga: https://taiga.maykinmedia.nl/project/open-inwoner/task/2638

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 98.38710% with 2 lines in your changes missing coverage. Please review.

Project coverage is 95.12%. Comparing base (8f22d47) to head (204dbdb).

Files	Patch %	Lines
src/open_inwoner/accounts/views/mixins.py	85.71%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           develop    #1336    +/-   ##
=========================================
  Coverage    95.11%   95.12%            
=========================================
  Files          995      998     +3     
  Lines        36472    36572   +100     
=========================================
+ Hits         34692    34790    +98     
- Misses        1780     1782     +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pi-sigma]

@swrichards

• I'm updating the klanten api by overwriting the get method of the CustomDigiDAssertionConsumerServiceView. Not entirely happy with this, as I had to copy over the code from the parent class and add the relevant function. I would have preferred to do this closer to where the user is created, but this is done by the DigiDBackend ouf our digid-eherkenning library. Suggestions welcome.
• I'm using the same method update_klant_api in different forms. Could be extracted since the code is the same, but I wanted to get some feedback first. Also, I wasn't sure what the best place would be to put this.
• The styling of the radio forms does not conform to design yet (it's missing the icons, and the radio buttons are aligned vertically instead of horizontally). Not sure if it's worth creating a separate component for this use case, or if updating our existing radio component is the way to go. Could also use input from @jiromaykin on this.

[swrichards]

• The styling of the radio forms does not conform to design yet (it's missing the icons, and the radio buttons are aligned vertically instead of horizontally). Not sure if it's worth creating a separate component for this use case, or if updating our existing radio component is the way to go. Could also use input from @jiromaykin on this.

Replied to the other points in separate threads, but for posterity: we agreed that this point would be handled separately in a future story.

[swrichards]

I have one more suggestion for the signal function, but it's not a blocker: if you don't get around to it, happy to merge as-is.

[alextreme]

This is fine for municipalities that make use of the eSuite Klanten API, nice work on that.

However, MG (see comment from Marieke in the design) doesn't use the eSuite Klanten API and also doesn't have a process interally for not sending updates via snailmail.

This case needs to be taken into account, otherwise citizens will check 'digitaal only' but still receive their updates via post.

[alextreme]

@swrichards see if you can re-review this PR, it's set to approved however new changes were necessary as discussed