FollowingRelationship storage & performance optimizations

FollowingRelationship storage & performance optimizations:

1. state is now ecto_enum-driven integer field mapped to FollowingRelationshipStateEnum. Storing enum-like fields as strings isn't a good approach, strings take much more space, prone to typos (unlike ecto_enum enum atoms — wrong atom couldn't be mapped to underlying integer value thus raising an error) etc.

2. Added an index on following_relationships.following_id since that would help existing queries (e.g. see Pleroma.User.Query.compose_query({:friends, %User{id: id}}, query)). Previous index on following_relationships.follower_id is just useless (and is removed in this MR) since Postgres can use another existing index on [:follower_id, :following_id] even when there's no condition on following_id in query.

Misc. tweaks: validation improvements in FollowingRelationship.changeset/2.

Note on chosen names for FollowingRelationshipStateEnum values: used :follow_pending, :follow_accept, :follow_reject for the moment for 2 reasons:

1. such are trivial to auto-replace with other ones should we need that (another benefit compared to hardcoded string values, btw), unlike :accept (atom is already in use in different contexts, so would be slightly harder to rename)

2. I have plans on merging FollowingRelationship into UserRelationship (IMO it should have been a type of UserRelationship initially but it was developed in parallel). We could either do it converting states to 3 new values in relationship_type (reusing existing index) or moving state as is, as a new integer field in user_relationships (so far leaning towards the latter approach). This way it'd be easier to preload all the relations (follow, mute, block etc.), it would have been done in one query (there are code parts requiring max. optimization of such preloads); also functions like follow_exists?/2 would be defined automatically (by existing code) etc.