Refactor Category to be Labels

[DanielNoord]

Refactor as requested by @ezio-melotti in #485 (comment).

Also couldn't help but notice the unused import so I removed it in a separate commit. If that's undesired I'll revert that change obviously!

[codecov]

Codecov Report

Merging #486 (4ea7afb) into main (6aebdb4) will not change coverage.
The diff coverage is 100.00%.

@@ Coverage Diff @@## main #486 +/- ##
=========================================
Coverage 100.00% 100.00% =========================================
Files 18 18 Lines 1815 1815 Branches 220 220 =========================================
Hits 1815 1815 

Flag	Coverage Δ
Python_3.10	100.00% <100.00%> (ø)
Python_3.11-dev	100.00% <100.00%> (ø)
Python_3.8	100.00% <100.00%> (ø)
Python_3.9	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
bedevere/prtype.py	100.00% <100.00%> (ø)
tests/test_filepaths.py	100.00% <100.00%> (ø)
tests/test_prtype.py	100.00% <100.00%> (ø)

[ezio-melotti]

I left a few minor comments but otherwise looks good to me.

However I'm a bit confused:

• the module docstring says "Label a pull request based on its type"
• the enum docstring talks about labels for PRs

but:

• classify_by_filepaths below calls util.issue_for_PR to retrieve the issue
• add_label/add_category accept an issue and label it

It would appear that is the issue being labeled, and if that's indeed the case, then the module docstring and the enum docstrings should be updated. (I think it's fine doing it in this PR.)

[DanielNoord]

• the module docstring says "Label a pull request based on its type"
• the enum docstring talks about labels for PRs

but:

• classify_by_filepaths below calls util.issue_for_PR to retrieve the issue
• add_label/add_category accept an issue and label it

I'm not sure about the gh.post method, but as I see it gh gets labeled (which is the PR) and the issue is being used to retrieve some data about the PR and its related issue.

So I think the current docstrings are actually correct. But somebody with more knowledge about the gh.post method can probably confirm this 100%.