Use requestData resources in UserPreferences

[matthew-white]

Right now, the UserPreferences class sends requests using the http object in container. However, the more typical pattern is for requests to be sent via a requestData resource. It wasn't easy before to do so in UserPreferences, but I've made some improvements to requestData to make that possible (#1050, #1051).

Right now, UserPreferences manually calls withAuth(). It also has to manage request cancelation. Those are both things that requestData already knows how to do.

This PR also removes navigator.locks, closing #1044.

What has been done to verify that this works as intended?

We don't yet have automated tests around user preferences: see #1049. However, I'll do a quick check of the behavior before merging the PR.

@getodk/testers, could you please check the user preference functionality during regression testing? (Maybe you were planning to already.) This PR makes changes to the underlying code, so it'd be good to verify that everything still works as expected.

Why is this the best possible solution? Were any other approaches considered?

One reason maybe not to use requestData resources is that resources have reactive state, and nothing about the UserPreferences.prototype.#propagate() method requires reactivity. However, I think it's fine for there to be a little extra reactivity: I don't expect there to be performance problems due to that. Overall, I think it's clearer to reuse the typical pattern of using requestData resources to send requests.

Before submitting this PR, please make sure you have:

• run npm run test and npm run lint and confirmed all checks still pass OR confirm CircleCI build passes
• verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced