[deepspeed] check whether model is NLP one instead of counting on input type
# What does this PR do?
This PR intends to fix an issue when training of NLP model fails if input dtype isn't int64.
My dataset had dtype = int32. Everything was ok until I decided to add deepspeed. 
It turned out that trainer relies on dtype and does input data convertion into hf_deepspeed_config.dtype if it isn't int64.
I guess it has to check whether first layer isn't Embedding instead. 

I think this PR also needs tests but I need an advice on how we can cover this case.  

@stas00 could you be so kind and review this PR and give an advice on whether tests are necessary and their implementation ?
_The documentation is not available anymore as the PR was closed or merged._<|||||>@izapolsk, I think the fix is much simpler. Just check if it's any type of `int` - I didn't think anybody would use a different int type than int64 when I coded this, so as new use cases come in, we can just adapt for it. 

```
            if self.deepspeed and data.dtype not in [torch.in32, torch.int64]:
                # NLP models inputs are int32 or int64 and those get adjusted to the right dtype of the
```

If it resonates and works you can go ahead and apply that fix, or I can do it as well. It'd be easier for you since you have an application you can already test with.

and if this will be the way, I don't think we need any additional tests.<|||||>Actually, I wonder why were we using int64 in the first place when vocabs are so small. int32 should work always and for smaller vocabs even int16 should be enough (max `32767`). 

Probably since there is very little saving in using a more compact dtype as inputs, if they are tokenized on the fly are very short.<|||||>@stas00, done.
I added more sophisticated check based on checking first layer because vocab could be int16 - 64 and there could be other non NLP models I'm not aware of having int input. 

Thank you for reviewing this PR.<|||||>Let me re-run the offline tests first<|||||>Nope, the tests were failing. The logic was incorrect. I pushed the fix.

@izapolsk, please check that with my fix it still works for you and then we can merge it.

Thank you.

p.s. Also since it seems that this is not the last of your deepspeed improvements, here is how you can test that your future PRs work:

```
RUN_SLOW=1 pytest tests/deepspeed
```

this is because CircleCI has no GPUs, so we only run those tests requiring gpus on a different CI nightly. <|||||>Oh good catch, missed that not. We'll need a quick rebase on main to get the quality job passing if possible (the failure seen here is fixed on main).<|||||>good catch, my bad, sorry. I'll do