Use "from securesystemslib import <mod>" instead of
"import securesystemslib.<mod>" to make securesystemslib compatible with
the vendoring tool.

Use "from securesystemslib import <mod>" instead of
"import securesystemslib.<mod>" to make securesystemslib compatible with
the vendoring tool.

Make hash module imports compatible with the vendoring tool.

This is trickier than the other cases:
* "hash" is a builtin function, overloading that with module name
  seems bad
* the resulting code "hash.digest(algorithm)" reads like hash is an
  object... Not ideal

Luckily there are few functions in the module: Import the functions
directly to avoid importing the module.

Use "from securesystemslib import <mod>" instead of
"import securesystemslib.<mod>" to make securesystemslib compatible with
the vendoring tool.

Use "from securesystemslib import <mod>" instead of
"import securesystemslib.<mod>" to make securesystemslib compatible with
the vendoring tool.

Import only the FilesystemBackend class when needed: this is
compatible with the vendoring tool.

Use "from securesystemslib import <mod>" instead of
"import securesystemslib.<mod>" to make securesystemslib compatible with
the vendoring tool.

Use "from securesystemslib import <mod>" instead of
"import securesystemslib.<mod>" to make securesystemslib compatible with
the vendoring tool.

The aim is to avoid potential conflict with 'process' module.

Use "from securesystemslib import <mod>" instead of
"import securesystemslib.<mod>" to make securesystemslib compatible with
the vendoring tool.

Rename the import to make it clear this is the python module, use an
import line that is compatible with vendoring tool.

Use gpg_util as local name to avoid potential conflicts with the other
util module.

Importing individual errors avoids conflict with the other exceptions
module in securesystemslib.

Use "from securesystemslib import <mod>" instead of
"import securesystemslib.<mod>" to make securesystemslib compatible with
the vendoring tool.

Importing the two functions individually seems reasonable here.

The results of the import is same, but new style is compatible with
vendoring tool.

Modify the way nacl and cryptography imports are made to make them
compatible with vendoring tool.

There is a circular dependency in
  gpg.constants -> gpg.rsa -> gpg.util -> gpg.constants

This is not a problem on python3 or python2 when the imports are done
with "import securesystemslib.<mod>" style. However with the
"from securesystemslib import <mod>" style python2 decides this is a
ImportError.

Remove the circular dependency by moving the module variables from
constants to another file.