Vocabulary & Modeling: Add the `Project` type (#163)
    
    The `Project` type is a way to group and nest forge/FSDL component
    actors, e.g. Repository, TicketTracker, PatchTracker, etc. for several
    purposes:
    
    - Covenient grouped display in UI when browsing, exploring, searching
    - Easy management for project team members
    - Possibility to grant/delegate OCAPs to a whole projecr rather than do
      it individually to every component, which is cumbersome and messy
    
    Properties `components` and `subprojects` are added as well.
    
    Q1: Why isn't Project a subtype of the AS2 Group?
    
    A: ActivityPub doesn't define any behaviors for Group, so the main benefit of this would be to share behavior with usage of Group on the Fediverse. This can be advantage (if the behaviors are aligned) but can also cause problems (if the behaviors conflict). I know people are doing group related things on the Fediverse, but I'm not personally aware of something established, so I prefer to protect us from conflicts for now. At any point, if it becomes helpful, we can make Project extend Group.
    
    Q2: Why use a custom property `subprojects` for children, but the AS2 `context` for parents?
    
    A: Because there's no good match for the children property in AS2 (I also looked at some RDF ontologies but couldn't find anything that really felt right). I'm considering to use a custom property for parents too, just for consistency, but not sure. `context` should work.
    
    Q3: Why does `subprojects` map to a `Collection` while `context` just lists parents without a `Collection`?
    
    A: There aren't clear guidelines for when to use a `Collection`, when to use an RDF `List` and when to use a simple multiple-values-for-a-property, but I'm observing a pattern that's used in AP, e.g. with `replies` and `inReplyTo`, and which makes sense to me:
    
    In a nested structure where parents have the authority about who their children are (because they provide them some service), and where parents can have many children but children have few parents,
    
    - the parents list the children using a `Collection` that can be paginated and items can be added and removed,
    - while the children, mostly just for information, list the parents they have and whose services they use.
    
    Parent projects provide a service to subprojects: They delegate access-to-them to relevant teams and people. And projects can have many children, but probably few parents, probably just 1 in mose cases. So, it fits the case described above. It also works the same with ForgeFed's ticket dependencies, for a similar reason.
    
    Co-authored-by: fr33domlover <fr33domlover@riseup.net>
    Reviewed-on: https://codeberg.org/ForgeFed/ForgeFed/pulls/163
    Reviewed-by: Aravinth Manivannan <realaravinth@noreply.codeberg.org>