Make scopes available to QQmlSA API as a separate entity; expose it to API

As evidenced by QTBUG-138346 , static analysis needs to reason about usage contexts, not only about types.

This is "easily" possible with QQmlJSScope, which is always both at the same time. However, that's a birth effect, or at least an evolutionary dead-end from how it was used. Instead, we should have a separate type  besides QQmlSA::Element, which is only about scopes, and the operations that make sense on scopes. We can still have well defined ways to transition from scopes to elements, e.g. a scope representing a QML scope should be able to return a QQmlSA::Element which corresponds to the type. Whether an Element should ever be able to return its defining scope is an open question. So is the question whether we need to represent JS functions/classes as types. At least initially, that part can however be skipped. 

Basically that yields an Element which loses parentScope and scopeType from its current API, and a new  QQmlSA::Scope  with methods like

• Scope parentScope()
• childScopes/beginChildScopes/endChildScopes
• QQmlSA::ScopeType  scopeType()
• std::optional<Element> qmlType()

Related: API like analyzeRead should arguably use the new Scope as readScope; however that might pose challenges for attached properties.