Fix other functions to conform with PEP 479

[augustomen]

As noted in https://github.com/petl-developers/petl/issues/575, there are still many places where RuntimeError could be raised as a result of an unhandled StopIteration when calling next(), due to PEP 479, which was implemented in Python 3.5.

This PR has the goal of properly handling headerless tables. This differs from empty tables in that an empty table at least has a header row (which could have no items in it - see petl.util.base.empty()). The real world use case for headerless tables are empty data-only CSVs (where the header is previously agreed between two systems), or development starting from an empty list - as is the case with all added tests.

A previous PR (https://github.com/petl-developers/petl/pull/613) solved the issue for the function iterrowslice. This PR expands this fix to (almost) all such calls. Although a little bit repetitive, I've decided to try..except all calls and handle them individually.

Changes

1. Handled every call to hdr = next(it) that could potentially raise an exception.
2. Added test cases for all these calls.

Notes

In some places, it made sense to let the exception be raised regardless, and in others it made sense to include a header row where one wasn't before. Namely:

• petl.util.base.header(): When no header is present, it makes sense to let an exception be raised (there was even a test for it). We may discuss if this should raise a custom exception instead of the generic StopIteration.
• addfield(), addcolumn() and similars: A header is added if none present.
• cut(), sort(), convert() and any others which depend on finding a header name: These will normally raise FieldSelectionError on empty tables, so instead of raising StopIteration I've mirrored the behavior on the former.
• petl.io.db, petl.io.avro and other formats that require field names: There is no such thing as a column-less table in RDBMS, so they will inevitably fail.

Checklist

Use this checklist to ensure the quality of pull requests that include new code and/or make changes to existing code.

• [ ] Source Code guidelines:
  • [x] Includes unit tests
  • [ ] New functions have docstrings with examples that can be run with doctest
  • [ ] New functions are included in API docs
  • [ ] Docstrings include notes for any changes to API or behavior
  • [ ] All changes are documented in docs/changes.rst
• [ ] Versioning and history tracking guidelines:
  • [x] Using atomic commits whenever possible
  • [x] Commits are reversible whenever possible
  • [x] There are no incomplete changes in the pull request
  • [x] There is no accidental garbage added to the source code
• [ ] Testing guidelines:
  • [x] Tested locally using tox / pytest
  • [x] Rebased to master branch and tested before sending the PR
  • [ ] Automated testing passes (see CI)
  • [ ] Unit test coverage has not decreased (see Coveralls)
• [ ] State of these changes is:
  • [ ] Just a proof of concept
  • [ ] Work in progress / Further changes needed
  • [x] Ready to review
  • [ ] Ready to merge

[juarezr]

@augustomen,

Sorry for the delay. I have to fix the GitHub actions before evaluating these changes.

Thanks for the PR.

[juarezr]

@augustomen,

As the CI was broken when you submitted this PR, I would like to check if everything is ok now after the fixes.

Could you rebase this PR before we proceed, please?

[juarezr]

Rebased and merged in #653