Wav2vec deviations from fairseq implementation
**Describe the bug**

I recently loaded the weights of a pre-trained "[XLS-R](https://github.com/facebookresearch/fairseq/tree/main/examples/wav2vec/xlsr)" wav2vec SSL model into the NeMo implementation and found a couple subtle deviations from the fairseq implementation that led to a different computational graph with the same state dict.

E.g., in the fairseq feature extractor, layer norm is applied [before](https://github.com/facebookresearch/fairseq/blob/5307a0e078d7460003a86f4e2246d459d4706a1d/fairseq/models/wav2vec/wav2vec2.py#L604) projecting the embeddings to the encoder dim whereas in the NeMo implementation the layer norm is applied [after](https://github.com/NVIDIA/NeMo/blob/8a172df69250da231742893387e9a1dd01b16e3d/nemo/collections/asr/modules/wav2vec_modules.py#L196).

After a couple changes I was able to run the XLS-R fairseq model in NeMo and get the same results from the feature extractor and encoder graphs.

**Are these deviations intentional?** It seems like most of the code is just copy-pasted except for these changes.

If these are intentional deviations, I will simply keep my patch local and close the issue.

If these deviations are accidental or if it would be useful to have an option to rearrange the graph to match the fairseq implementation, I will submit my changes.


