Previously in SERVER-100173 we added 'expression' was added as a 'combination.method' option.

In this implementation, we added support for referencing collection level fields in the expression. However, the way we did it the user has to append the prefix 'docs.' to these fields to reference them.

The reason we need the 'docs.' prefix is because the original user document (the direct output structure of the documents in the collection) are all under a subfield called 'docs' while we intermediately process the documents in $scoreFusion, before restoring the user document structure.

Instead, we want to be able to reference these fields without the 'docs.' prefix (as this prefix is essentially an implementation detail of the stage that should not be exposed to the user). Here are two half-baked ideas / approaches to this task:

1. Somehow alter the de-sugaring to not fold the collection level fields under a the 'docs' field
   1. Problem - how would we differentiate between our internal processing fields and the user fields?
2. Post process the provided user expression and prepend the 'docs.' prefix to the collection fields
   1. This doesn't sound super simple... what about complex expressions with nested references to collection fields? This would require a decently complex recursive approach.

This task may end up proving difficult (as it may alter the stage structure of desugaring significantly, or require complex parsing of an Expression), and require more investigation / discussion before executing. 

Note: we maybe should sync with product first before executing this ticket and ensure that the 'docs.' prefix is indeed unacceptable, and that there is no existing precedent for this (see comment here).