text: Title: Swagger's preauthorize_apikey feature
  Body: Currently there is no "flask_restx" way to use the Swagger ``preauthorize_apikey`` feature. (You can always patch the javascript returned by apidoc using the Api.documentation decorator, but it seems to be the worst way to do it)
  
  We needed this feature, in order to display Swagger documentation allready "populated" with user's apiKey. Our use case :
  - a user login with login/password couple in order to fetch an api Token and see swagger doc
  - when displaying swagger documentation for this authenticated user, the curl example should contains the Token argument
  
  I wrote two commit implementing this feature in two ways :
  - https://github.com/yweber/flask-restx/commit/4c6955eadaa4c93ec8fe6d14d322e1ec01ecc9e3
    - a straight-forward template modification using a global Flask.config item referencing a function returning preauth informations
  - https://github.com/yweber/flask-restx/commit/85310b3eadbb3d94b18bfecf083fc8cb9c5c6753
    - adding a decorator to ``flask_restx.Api`` class in order to register a function returning preauth informations
  
  Both PR will be created soon.
  
  
  I don't know wich one is the better nor wich one fits best with flask_restx philosophy.
  
  - the global configuration solution is.... global : you register a function once and it will be used for all Api instance. It will be messy if different apiKey swagger's authorization names are used
  - the ``Api.apikey_preauthorization`` decorator allows to register a preauth information function per Api : you have to do it for each Api instance with swagger ``preauthorize_apikey`` enabled
  - Right now, registered functions do not takes any argument. With the decorator's solution it seems to be trivial to pass the ``flask_restx.Api`` instance as argument. I'm not a flask expert, but it looks like it is useless : the flask application context is accessible globally (with ``Flask.current_app`` or ``Flask.session`` etc.) Is there a use case where this function would like to access the current ``flask_restx.Api`` instance ?
  
  Finally, a mixed solution is possible :
  - merging the configuration and the decorator : allowing both with a priority on the function registered with the decorator
  
  Thank's for your time reading this issue (and the associated PRs :) ) !