fix(schema-compiler): Handle measures with dimension-only member expressions

[mcheshkov]

Check List

• Tests have been run in packages where changes made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet
• Docs have been added / updated if required

Description of Changes Made (if issue reference is not provided)

fullKeyQueryAggregate is using measure.cube() a lot, like for grouping measures to key cube
This can be wrong for measure targeting view: we want to attach measure to subquery
for its definition cube, and there should be no subquery for view itself
It's expected that fullKeyQueryAggregateMeasures would resolve and prepare all measures from its original form in query to actual leaf measures in cubes, then build subqueries with those, and then joinFullKeyQueryAggregate would use renderedReference to point to these leaf measures

Hard case is a measure that:

• targeting view
• is a member expression
• references only dimensions from that view
  Measure like that are "leaf" - there's nowhere to push it, member expression has to be directly in leaf subquery
  If measure references dimension from a single cube it can be multiplied (think SUM(${view.deep_dimension}))
  So, three points:
• it must be accounted for in multipliedMeasures
• it must be attached to a proper cube subquery
• it must use renderedReference correctly

collectRootMeasureToHieararchy will not drop such measure completely. Now it will check is there's 0 measures collected, try to collect all referenced members to gather used cubes and detect multiplication, and add new measure in hierarchy.

Because new returned measure is patched, it will be attached to correct cube subquery in fullKeyQueryAggregate

Then outerMeasuresJoinFullKeyQueryAggregate needs to generate proper alias for it, so outer unpatched measure would pick up alias from inner patched one

Finally, checkShouldBuildJoinForMeasureSelect has to be adjusted: it collected cube names and join hints, and for dimensions-only measures on views it would collect too many, and decide that measure is multiplied, when it should not. So now it first collects non-view members, and then collect cubes and join hints from those.

[waralexrom]

Maybe we should put this part related to the member expression over dimension into a separate function and just call it here? There is a lot of code inside the lambda function - it's quite hard to read.

[waralexrom]

Maybe it would be better to use ownedByCube here?
Something like

const nonViewMembers = memberNamesForMeasure
         .map(m => this.memberInstanceByPath(m))
        .filter(mem => {
          
          return mem.definition().ownedByCube;
        });