Refactor text to use virtualfile_from_vectors instead of pandas tempfile

[weiji14]

Description of proposed changes

Non user-facing refactor to avoid the use of temporary files in the original text implementation at #321.

Enhance the text implementation by allowing a list/array of angle/font/justify inputs. Something like so: Note: below code will not work yet.

import pygmt

fig = pygmt.Figure()
fig.text(
    x=[5.0, 6.0],
    y=[6.0, 7.0],
    angle=[30, 60],
    justify=['BL', 'TL'],
    font=['16p,2,blue', '32p,3,red'],
    text=["First label", "Second label"]
)
fig.show()

Note that this requires GMT 6.1.1, as mentioned in #520, so it won't work yet. It works now.

One step towards fixing issue at #483

Reminders

• Run make format and make check to make sure the code follows the style guide.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Add new public functions/methods/classes to doc/api/index.rst.
• Write detailed docstrings for all functions/methods.
• If adding new functionality, add an example to docstrings or tutorials.

[seisman]

This PR should work after we bump 6.1.1. Please update this branch and see if it works.

[seisman]

This PR is already a good improvement (avoid using temporary files), although it doesn't fix #483.

I think we can remove the Fixes #483 comment in the top post and merge it.

[weiji14]

Ok, I'll update the branch.

[seisman]

Is it more readable to rewrite the codes to:

if kind == "file":
   ...
elif kind == "vectors":
  ...
else:
  ...

[weiji14]

Yes it would be more readable. I think the only reason I wrote it that way was because pylint complained about too many if-statements:

R0912: Too many branches (13/12) (too-many-branches)

If readability is more important, I can increase the branch limit on our .pylintrc file, or I can try refactoring more of the code in text to reduce the number of if-statements. OR, we can just merge this in now and worry about it in the next PR that will fix #483.

[seisman]

OR, we can just merge this in now and worry about it in the next PR that will fix #483.

OK to me.