[Good first issue] Support relative paths with CommonJS and non-unified output

# Problem

Currently, in relay-typegen/src/lib.rs, if we're using CommonJS and don't have unified output (meaning that we emit all generated files to a location that is relative to where the source file exists), we emit "any" types for
* fragment refs types, and
* variable types used by generated refetchable queries.

Source: https://github.com/facebook/relay/blob/main/compiler/crates/relay-typegen/src/lib.rs#L521-L523 and https://github.com/facebook/relay/blob/main/compiler/crates/relay-typegen/src/lib.rs#L1387-L1389.

Concretely, this means that we emit lines like

```
type someFragmentUsedInThisQuery_type$fragmentType = any;
```

As a consequence, for users who use common js and non-unified output, we do not prevent you from passing the wrong fragment ref to useFragment. The following is not prevented by flow/typescript, and will throw at runtime:

```
const data = useLazyLoadQuery(graphql`
query Foo {
viewer { ...SomeFragment_viewer }
}
`, {})

const data = useFragment(graphql`fragment ADifferent_viewer { __typename }`, nullthrows(data.viewer))
```

# Potential solution

* Pass the normalization program to the typegen
* This may be big enough for a PR on its own.
* If this becomes a quagmire, we can add a transform pass that adds an internal directive containing the relative path to the fragment. Search for e.g. `ASSIGNABLE_DIRECTIVE_FOR_TYPEGEN` or `RELAY_ACTOR_CHANGE_DIRECTIVE_FOR_CODEGEN`
* Via the program, go from fragment name -> fragment definition -> location of fragment literal -> location of generated file
* Emit a relative import to the generated file

# Other

* Please make separate diffs for the fragment ref and refetchable variables case.
* Our tests use common JS + non-unified paths. Regenerating those should show the correct paths.
* Feel free to reach out on the graphql discord, relay channel, if anything is unclear!