GoogleNet and Inception return different types depending on train / eval mode

Googlenet and Inception have two different return types, depending on train / eval mode.

This is necessary only during training, because the original models have auxiliary classifiers, which are not used for inference.

The current structure of the models might be seen as an artifact on how they were trained.
One other way of seeing it would be that, if we could return arbitrary intermediate outputs, then during training we could plug the auxiliary classifiers outside of the model, and perform training there, but the model by itself doesn't have those auxiliary classifiers.

We should consider if we would be willing to change this, which would be a BC-breaking change.

Advantages:

• simplifies torchscript support for those models
• unifies the return value of the model during training and testing

Disadvantages:

• BC-breaking
• training those models would require custom code to add the auxiliary heads. But this is not a real disadvantage because we haven't reproduced those models with the current training code anyway.

Start by reviewing the GoogLeNet and Inception model implementations and their current training and evaluation return paths. Determine whether a unified return value can support TorchScript and auxiliary classifiers without preserving the existing behavior, then document the compatibility decision and affected training code before proposing a change.