[chore/refactor] Sort out `properties.go` and `extract.go` in `internal/ap`

[tsmethurst]

Right now we have a lot of sort of overlapping functions split between internal/ap/extract.go and internal/ap/properties.go. The functions in extract contain a bit more business logic and the functions in properties are more like simple getter and setter wrappers, but this isn't immediately clear at first sight, and there are functions in each file that could probably just as easily be included in the other.

We should try to sort these out to reduce overlapping concerns and make it clearer which (set of) functions should be used for what, and maybe divide them into subpackages if necessary.

[NyaaaWhatsUpDoc]

i wouldn't mind going through and doing this at some point.

basically my methodology in starting to setup a bunch of the getters / setters in properties.go was that easy getting and setting of properties can go in there, but the more complex extractions e.g. entire database model types can then go in the extract.go set of functions. also given the way that go-fed/activity is written and it gives the possibility to error check a truly unfathomable amount, i generally only error check when it's a useful error we can actually return. which is why most of the getter / setter functions don't feature actual error checking, and instead refer to the caller to determine whether a missing value is actually an error or not. being able to log / return "X object in activity is malfored" is still (almost) as useful as saying which exact field within it is malformed, but it results in much more concise code for us.

sorrry if that's a bit rambly, that's just generally what i've been keeping in mind whenever going over any of that area of the codebase. obviously all input / feedback welcome here @tsmethurst / any other gotosocial devs reading this :D