Modify Brave Sync UI to allow one device in chain

Description

This issue is an required addition for PR https://github.com/brave/brave-core/pull/3988 .

General notes: Sync should allow to have just one device in the chain.

This will help to avoid the situation mentioned in https://github.com/brave/brave-browser/issues/6504. Or with these hypothetical STRs:

1. enable sync on desktop
2. get busy doing something else
3. enable sync on mobile
4. shut down browser and go home
5. mobile never gets the data from the desktop because it was waiting for a second device to start syncing
6. User is angry because sync doesn't work as a user you would think that since you had enabled sync on the desktop a long time ago it should have synced everything already and then you can just connect your mobile device and get that data . 

**Required changes: **

1. If brave://sync page is loading/reloading/sync state changed, and sync is enabled, but there are less than two devices, SyncUI page should show View Sync Code dialog.
2. If View Sync Code is being shown, but there are less than two devices, then when the dialog is closed by cancel, SyncUI should not call Reset, and should just show the regular devices list screen and buttons.

@bradleyrichter, @darkdh , @bridiver could you please review the requested changes?

@cezaraugusto, ~you should work in branch of https://github.com/brave/brave-core/tree/sync_prefs_redo_issue_6504 , because it contains the service side changes to allow to have less than two devices in chain.~ The commit Changes in sync UI to allow test of service - subject to be redone - should be removed because it is just my attempt to allow page work when < 2 devices, so it is rough and not correct.

[cezaraugusto]

@btlechowski thanks for reporting. on it right now.

@rebron yes there is a PR open for this but @AlexeyBarabash pointed me out that additional work was required, which I’m working on at this very moment.

[LaurenWags]

Marked as release-notes/exclude as per discussion with @btlechowski this was actually implemented with 1.3.x but this issue was not included in that milestone. cc @kjozwiak