[fsmt test] basic config test with online model + super tiny model
This PR does:

* [x] Seeing the issue of https://github.com/huggingface/transformers/pull/7659 I realized fsmt didn't have a basic non-slow test that loads the tokenizer via online model files. Luckily a totally unrelated examples test caught this issue in that PR, so adding a very simple quick test in the main test suite, so that it runs by the normal CI.
* [x] while I was building this test, I needed a new tiny model, so I refined the script https://github.com/huggingface/transformers/blob/master/scripts/fsmt/fsmt-make-tiny-model.py and made a new one that creates a 50 times smaller model, so we are now at 60KB, instead of 3MB.

@LysandreJik, @sshleifer 

Hi Stas, thanks, #7659 will fix this (we will now require at least one example checkpoint for each tokenizer and we test it automatically).<|||||>@thomwolf, I'm not certain why you closed this. This is a tokenizer test that is needed - the issue caught in examples was just a flag that there was a missing test in the normal tests.

Actually, not only it's needed, I will have to expand this test to verify that it **doesn't** get the hardcoded default values, but fetches the correct values from `tokenizer_config.json`. And to change the default values to be different from `TINY_FSMT`, since otherwise it won't be testing the right thing. 

Feel free to add it as part of https://github.com/huggingface/transformers/pull/7659 but please make sure you used different from `TINY_FSMT` hardcoded defaults.

I hope this makes sense. <|||||>Hmm, but you copied `TINY_FSMT` in https://github.com/huggingface/transformers/commit/1885ca7f29ffa5373ea848edad8efab02809c268, how will then the tests check it can fetch that data if this is now hardcoded? I am not following this. Do I need to create `TINY_FSMT2` with different values?

I haven't read the new code in depth, but my gut feeling is that the defaults may mask a problem.<|||||>Hi stas, I'll let you read the new code and then we can have a look together.

The basic idea is that we now require a full and working checkpoint for the tokenizers to be fully tested in various conditions and the slow vs. fast compared.

The question of testing that tokenizers load and use `tokenizer_config.json` is another question and we should indeed address it in a subsequent PR if it's not addressed already indeed.<|||||>That works. 

But please re-open this PR, since we need it anyway. I will add more changes to it after your big PR merge to ensure that the loading of the tokenizer is properly tested.<|||||>This PR is complete now.