Fix Vue warnings about the Member component in component tests

Closes #1052 (closed). One step closer to actually getting working tests with Vue 3…

Vue was printing very unhelpful messages, so I had to coax it into showing actual errors. I couldn't find any magical setting to do it, so I used a terrible idea instead:

grep -lr '\[Vue warn\]' node_modules/@vue | while read name; do sed -i "s|\[Vue warn\]|\[$name\]|g" "$name"; done

This causes the dozen or so files that have logs for Vue warns to replace [Vue warn] with their filename. This will let me figure out which of the dozen files within node_modules are actually used within the tests.

This resulted in the following warnings:

[node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js]: Unhandled error during execution of render function 
  at <Member member= {
  id: 'member_id',
  level: 20,
  user: { id: 'user_id', email: 'james@test.me', display_name: 'James' },
  group: null
} ref="VTU_COMPONENT" > 
  at <VTUROOT>

I could then edit node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js to force the original error to be printed:

--- node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js.orig	2022-08-24 17:52:03.006411153 +0200
+++ node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js	2022-08-24 17:52:29.438228643 +0200
@@ -922,6 +922,7 @@ function renderComponentRoot(instance) {
     }
     catch (err) {
         blockStack.length = 0;
+        console.error('LOL', err);
         handleError(err, instance, 1 /* RENDER_FUNCTION */);
         result = createVNode(Comment);
     }

This got me to see the actual error:

LOL TypeError: Cannot read properties of null (reading 'email')
    at Proxy.isLoggedUser (/home/lucidiot/dev/ark/frontend/dist/webpack:/arkindex/src/components/Memberships/Member.vue:160:63)
    at ReactiveEffect.run (/home/lucidiot/dev/ark/frontend/dist/webpack:/arkindex/node_modules/@vue/reactivity/dist/reactivity.esm-bundler.js:185:1)
    at ComputedRefImpl.get value [as value] (/home/lucidiot/dev/ark/frontend/dist/webpack:/arkindex/node_modules/@vue/reactivity/dist/reactivity.esm-bundler.js:1144:1)
    at Object.get [as isLoggedUser] (/home/lucidiot/dev/ark/frontend/dist/webpack:/arkindex/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:3428:1)
    at Proxy.render (/home/lucidiot/dev/ark/frontend/dist/webpack:/arkindex/src/components/Memberships/Member.vue:5:18)
    at renderComponentRoot (/home/lucidiot/dev/ark/frontend/dist/webpack:/arkindex/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:896:1)
    at ReactiveEffect.componentUpdateFn [as fn] (/home/lucidiot/dev/ark/frontend/dist/webpack:/arkindex/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:5652:1)
    at ReactiveEffect.run (/home/lucidiot/dev/ark/frontend/dist/webpack:/arkindex/node_modules/@vue/reactivity/dist/reactivity.esm-bundler.js:185:1)
    at instance.update (/home/lucidiot/dev/ark/frontend/dist/webpack:/arkindex/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:5695:1)
    at callWithErrorHandling (/home/lucidiot/dev/ark/frontend/dist/webpack:/arkindex/node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js:155:1)
[node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js]: Unhandled error during execution of render function 
  at <Member member= {
  id: 'member_id',
  level: 20,
  user: { id: 'user_id', email: 'james@test.me', display_name: 'James' },
  group: null
} ref="VTU_COMPONENT" > 
  at <VTUROOT>
[node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js]: Unhandled error during execution of scheduler flush. This is likely a Vue internals bug. Please open an issue at https://new-issue.vuejs.org/?repo=vuejs/core 
  at <Member member= {
  id: 'member_id',
  level: 20,
  user: { id: 'user_id', email: 'james@test.me', display_name: 'James' },
  group: null
} ref="VTU_COMPONENT" > 
  at <VTUROOT>

This TypeError is caused by the Member component expecting a logged-in user, and not handling the case where there is none. This currently could not occur in the real frontend, because the Member component is always used within routes that are marked as requiresLogin and requiresVerified. However, the Vuex store is completely empty within unit tests, so there never is any logged-in user. Handling the issue on the component side rather than setting a logged-in user in each test is much easier.