nvptx: Gracefully handle '-mptx=3.1' if neither sm_30 nor sm_35 multilib variant...

nvptx: Gracefully handle '-mptx=3.1' if neither sm_30 nor sm_35 multilib variant is built

For example, for GCC/nvptx built with '--with-arch=sm_52' (current default)
and '--without-multilib-list', neither a sm_30 nor a sm_35 multilib variant
is built, and thus no '-mptx=3.1' sub-variant either.  Such a configuration
is possible as of commit 86b3a7532d56f74fcd1c362f2da7f95e8cc4e4a6
"nvptx: Support '--with-multilib-list'", but currently results in the
following bogus behavior:

    [...]/xgcc -print-multi-directory -mgomp -march=sm_52
    mgomp
    [...]/xgcc -print-multi-directory -mgomp -march=sm_35
    mgomp
    [...]/xgcc -print-multi-directory -mgomp -march=sm_30
    mgomp
    [...]/xgcc -print-multi-directory -mgomp -march=sm_35 -mptx=3.1
    .
    [...]/xgcc -print-multi-directory -mgomp -march=sm_30 -mptx=3.1
    .

The latter two '.' are unexpected; linking OpenMP/nvptx offloading code
like this fails with: 'unresolved symbol __nvptx_uni', for example.
Instead of '.', the latter two should print 'mgomp', too.  To achieve that,
we must not set up the '-mptx=3.1' multilib axis if no '-mptx=3.1'
sub-variant is built.

	gcc/
	* config/nvptx/t-nvptx (MULTILIB_OPTIONS): Don't add 'mptx=3.1' if
	neither sm_30 nor sm_35 multilib variant is built.