Fix: Make Schema reactive in AutomaticInfobox

[JeroenDeDauw]

Schema was fetched once at mount time and never updated, so changes
made via the SchemaEditor were not reflected in the infobox until
page reload. Wrapping it in computed() makes it reactive.

Steps to reproduce:

1. Open a page with a Subject infobox (e.g. Professional Wiki)
2. Click edit on the infobox to open SubjectEditorDialog
3. Open the schema editor and change a property type (e.g. change
   Websites from URL to Text)
4. Save the schema and close the dialogs
5. Bug: the infobox still shows the old property type until reload

Manually verified, both the bug and the fix

[JeroenDeDauw]

Looking at this made me wonder about the current behavior (on master and in this PR): if we open the schema editor via the subject editor and then save our change there, it is globally saved, even though we did not confirm our changes in the subject editor yet.

Alternative approach is that the SchemaEditor does not save when opened via the subject editor. Instead it has a "back to editing subject" type of button that just changes the local schema in the subject editor, and then the subject editor saves both subject and schema upon close. Tho that also comes with some weirdness and some complication around edit summaries and such.

[alistair3149]

We should save in SchemaEditor directly because users might be using the SubjectEditor to get to the SchemaEditor, in which there are only changes to save for schema but not the subject.

[malberts]

On the other hand, if I just want to see what my Subject is going to look like with some Schema changes, and decide against it, then I have no easy way of reverting the Schema changes that were already saved in SchemaEditor (besides going to the Schema page and reverting a revision).

IMO the UX is a bit awkward in the "I want to edit only the Schema" use case, since you are forced to open 2 forms, but only use 1. I still think the Schema label in the Infobox should be interactive, perhaps similar to the Schema link behavior in SubjectEditor. In this case my intention of "doing something" specifically with the Schema is more explicit. Why am I editing John when I want to edit Person?

Also, internally we have SubjectEditor and SchemaEditor, but from the user's perspective, am I editing the Subject and Schema, or the Infobox (everything as a whole)? If I'm editing the Infobox, then it would seem like everything should be saved together at the end when I'm done updating "the infobox". Whereas if I'm editing only the parts, and it is explicit in the UI, then saving separately makes sense. In Coda and Notion this distinction is blurred, because both parts are updated in the same form, and they don't have explicit save buttons, so every individual change gets saved immediatelly anyway.

[JeroenDeDauw]

Excellent points. I saved this in my notes to revisit soon when we look at Views again

[JeroenDeDauw]

I still think the Schema label in the Infobox should be interactive, perhaps similar to the Schema link behavior in SubjectEditor.

Yes please. You create task or fix?