Do not crash UI for "unknown" calendar models

[thiemowmde]

This patch does two things:

1. Lazy detection of the Julian calendar model. This will, for example, detect http://www.wikidata.org/wiki/Q1985786 (note the word "wiki" instead of "entity") and do the right(tm) thing.
2. All other URLs are ignored and assumed to be Gregorian.

This probably conflicts with #61 by @snaterlicious, but I wanted to store it so we don't forget.

I can split this into two patches, if this helps in getting this merged faster.

Bug: T89698

[snaterlicious]

Please, no. If I perceive the problem correctly, it should not be worked around like that. There seems to be something seriously broken on how calendar models are referenced. There should be one dedicated "ID" for each calendar model (which happens to be the Wikidata Item ID encapsulated by a dedicated URI which is acting like an ID). Apart from the fact that having an URI as ID might be kind of odd as the Item it references can be access using different URIs, are there going to be multiple references (URIs) to single calendar models in the data base then?

[thiemowmde]

Are you referring to 1. or 2. or both?

I'm not saying this is the best fix, but the fact that this just crashes the whole UI is a bug and needs a fix. Pinging @lydiapintscher.

[snaterlicious]

(1) is more of a conceptual issue and I sincerely doubt it belongs into the code in any way. (2) should indeed be fixed. However, not by removing throwing an error but rather by catching an resolving it. That should be done on a higher level (in Wikibase) as the code here is not supposed to make fall-back assumptions. The error is bubbling up to jQuery.snakview.variations.Value._setValue() and on to jQuery.wikibase.snakview.variations.Variation.value(). One of these functions should wrap the call causing the error in a try-catch block.

[brightbyte]

@snaterlicious: is an unknown calendar model actually an error? To me, it's just a non-default cause, one we don't provide pretty UI for. But it's perfectly valid. Otherwise, the API should reject it (and even if the API started to reject them, we may still get them from the database).

[adrianheine]

@brightbyte It's currently an error because we cannot even represent them. It should not be an error, just as non-default precision values are not an error.

[thiemowmde]

Discussion moved to https://phabricator.wikimedia.org/T89698#1088683.