refactored repeathandler customization in the Pages module, #728

[MartijnR]

@kkrumlian, @gushil, @pbowen-oc, as discussed, here is an example (an exceptionally nice one tbh) to demonstrate the kind of refactoring I propose to do in the monorepo.

The previous approach was taken to be able to keep using the official enketo-core npm module without forking it. This is no longer required with the monorepo.

Advantages:

• reduced change of surprises if enketo/enketo updates this function in the enketo-core package
• less change of confusion if OC is trying to identify and fix a bug in this function (since the function exists in 2 places, where one is a complete or partial overwrite)
• less code (both original and overwritten functions exist in the JS bundle in enketo-express-oc)
• much easier to identify customizations by looking at the diff with enketo/enketo. If an existing function is customized, the customization shows where it occurs (instead of somewhere else).

Disadvantage:

• increased change of merge conflicts when merging from enketo/enketo (but that may be seen as an advantage because it flags potential bugs created by the merge if the function in enketo-core changes substantially and the overwrite no longer works)
• some 3-10 hours of work to do this refactoring plus additional testing load by OC

When refactoring is done the whole page.js file in enketo-express would be removed as all its customizations would have moved to enketo-core.

[MartijnR]

PS. don't approve and merge this as it still requires more work. It is just useful to show the approach for now.

[MartijnR]

There is a failing test (enketo-core web) that I cannot reproduce locally. For now, it's okay to ignore and ready for review.

I'll add the other PRs on top of this one, so please review the PRs in order.