[UI] Add missing properties to global configuration

[smessie]

Follow-up to #869, which added the global configuration in PR #900.

Two properties are described elsewhere in the specification as global configuration properties but were missing from the property table of the SHACL Global Configuration section.
This adds both, and extends the sample instance data so it covers the same properties as the table above it.

What this adds

• shui:defaultWidgetScore. Read by scoring graph preparation as the score for a widget that a shape declares with shui:editor or shui:viewer and that the scoring graph does not otherwise score.
  Defaults to 40. That section carried an editorial note asking for this row once PR Issue 869: toward a global configuration for SHACL UI #900 landed; the note is now removed.
• shui:defaultOrder. Declares the effective order assumed for property shapes and property groups that do not specify sh:order, as defined in Grouping, Ordering, and Layout Hints.

Both rows state the permitted datatypes, xsd:decimal and xsd:integer, matching what shui:score and sh:order respectively permit.

• See this document rendered online here

[bergos]

Remove that part. See #1195

[danielbeeke]

I initially thought this wasn't related to the referenced PR, but it turns out it is.

The core question here is: Do we want a shui:defaultWidgetScore that applies when no scoring shapes are added to a widget? Why would we need scoring shapes here? This situation was actually introduced by the merged PR.

To recap what that PR changed:

• Preserved default behavior: Users can still create widgets without explicit score shapes.
• Maintained spec compatibility: Hardcoding widgets via shui:editor and shui:viewer is still supported.
• Preprocessed score graphs: Added score shapes to widgets missing them during a preprocessing phase (aligning with the proposed approach for data-only SHACL renderers without shapes).
• Simplified scoring outputs: The previous scoring algorithm forced implementations into an awkward state where score and select functions had to return either a single IRI (if best was true) or an array of ScoreResults. This was difficult to implement, hard to read, and led to maintainability concerns. We restructured this to align with the task force’s overall vision. Also slect and score did not differ a lot from each other, but were different enough to need two functions.

It seems @bergos wants the ability to hardcode widgets without relying on the scoring system. These differing architectural viewpoints are currently blocking progress across multiple issues.

Proposal: Before proceeding further, let's explicitly resolve the core architectural questions regarding spec functionality, conformance, and whether we are targeting a single normative core or supporting multiple profiles as that is at the heart of this issue.

[bergos]

Remove that part. See #1195