`case_sparql_select` should support running queries against just the built-in ontology

[ajnelson-nist]

There are some use cases that would benefit from being able to run a SPARQL query without needing to independently supply a data graph, because the data being queried is the ontology. For instance, CASE-Mapping-Template-Stubs Issue 10 just needs to ask about where properties go, irrespective of instance data.

Possibly a new calling pattern can be introduced, where if there's no data graph, the built-in ontology is loaded as subject data:

case_sparql_select output.md input.sparql

This would need to cover behaviors with --built-version, e.g. running some query to see if there is different results between CASE 1.1.0 and 1.2.0:

case_sparql_select --built-version case-1.1.0 output-1.1.0.md input.sparql
case_sparql_select --built-version case-1.2.0 output-1.2.0.md input.sparql

This would also need to cover how to load the full ontology as a supplement to a subject-data graph. A no-parameter flag feels right reflexively, but introduces the following call patterns. Probably fine, but worth looking at with fresh eyes before coding.

# The latter 2 call forms would do the same thing.
# (All three do the same thing if `input.jsonld` is an empty graph.)
case_sparql_select --load-ontology output.md input.sparql input.jsonld
# vs.
case_sparql_select --load-ontology output.md input.sparql
# vs.
case_sparql_select output.md input.sparql

[ajnelson-nist]

This Issue should also apply to case_sparql_construct.

[ajnelson-nist]

Additionally, there are use cases for trying SPARQL queries that aren't necessarily data-interactive, such as checking function syntax. E.g.,

SELECT ?x
WHERE {
  BIND( UUID() AS ?x )
}