Custom close codes

[folospior]

See rawhat/gramps#3.

In essence, in addition to the standard 1000 close codes, APIs can define their own. This PR brings things up to date with the gramps PR.

Note: PR is a draft because it currently has a git dependency on my fork. Will change once gramps PR is approved and pushed to Hex.

[folospior]

Here we go, took a lot of retries but I got it right (PC format and my git config wasn't quite right).

@rawhat Ready for review :)

Planning to add some features later on (more close reasons, on_close w/CloseReason [i actually depend on it lol])

[folospior]

By the way, I actually implemented an on_close function with close reasons (to be able to pattern match based on what we receive from the server), do you think I should merge that branch into this PR or make a separate one once this is done (or as a draft)

I'll make a new one once this is merged, please don't make a release until then (to avoid two major releases)

[folospior]

@rawhat Cleaned up the mess :)
Will rebase folospior#1 when this gets merged

[folospior]

Will rebase folospior#1 when this gets merged

At least I hope I can, I haven't dived into stacked PRs before 😅

[rawhat]

from an ergonomics perspective, do you think making the CloseReason non-opaque and just keeping the close and close_with_reason as the only public functions? i'm not really a user of this library, so curious about your perspective

[folospior]

Now that I think about it, I think you got a point. The only close reason that actually needs to be opaque is the custom one, so that could be in its own opaque type with its own function. I'll get around to it in a few. It could introduce some naming problems with sent and received close reasons, but it's not anything we can't figure out.

[folospior]

I also added some labels and bugfixes (preventing negative and invaid close codes), I hope these won't be an issue (I should've split commits 😞)

[rawhat]

Thank you!