Add Slycot exception and warning classes

[bnavigator]

As proposed in #99, I am introducing the new Exceptions SlycotError, SlycotParameterError and SlycotArithmeticError. So to never forget the .info attribute again!

Fixes #99

[repagh]

Forcing a "None" positional parameter looks a bit ugly to me. For the rest, I like this initiative.

[repagh]

Ow. That went quicker than I thought. It seems I was able to push on your branch, if hope you like the modification, if not, ignore/revert.

One of the advantages is that this reduces the number of lines; fewer lines - better coverage.

Look, nice improvement:

coverage/coveralls — Coverage increased (+25.1%) to 68.396%

[bnavigator]

I like it, but right now the raise from docstring always raises SlycotParameterError even when it should be SlycotArithmeticError. Working on this right now

[repagh]

I think I accidentally did a wrong force-push, trying to fix the loose ampersand. :-(

[bnavigator]

Yeah, you discarded my edits. No worries, will fix that in my next commit. Probably need to rebase a little bit.

[bnavigator]

Look, nice improvement:

coverage/coveralls — Coverage increased (+25.1%) to 68.396%

It's cheating though because we now parse stuff that is not counted by coverage. ;)

[repagh]

Nice work, you lifted it to a whole new level.

Some additional points

• I see you removed the parsing check from test_sb.py. I worked on an easy routine to verify that a docstring can be parsed for the exceptions that we think are in there. That would offset the "cheating"?
• I am getting these complaints from git that the recent commit messages have a & and a <, fix or ignore?

[bnavigator]

Yes the original parsing check did not work anymore as the new parser does not return the complete list.

Will fix the commit messages in the next rebase, where I also fix your "merge" commit. Right now I am getting gihub connection errors on git.

I am working on extending this to "Warns" also. There are quite a few routines that use the info parameter for warnings but want to return partial results.

[repagh]

Looks good. However, I think we should raise a catch-all exception when we don't find the (non-zero) info value. Otherwise a (future) programming mistake might lead to someone happily accepting erroneous results.

[repagh]

looks good. I remarked some final issues

[repagh]

Looks perfect now. Any objections to a merge?

[bnavigator]

As soon as you said it's perfect, I broke it ;) Fixed now.

With all the numpydoc changes, this is hard to review. Let's give @roryyorke a little bit of time to see if he has any objections.

[roryyorke]

This looks great, thanks for all the work.

Besides #99, I image it goes a fair way to addressing #100.

_parse_docsection is a quite complex, but it's an internal tool, so that's fine.

I skimmed over the changes to analysis, synthesis, and math; it generally looks much tidier, and less code is always good.

[bnavigator]

So, time to merge and focus on the release before we get new ideas? ;)