[4.0] Introduce category factory

[laoneo]

As discussed on skype, moves the category instance creation code into a factory.

I'v also extended it with a new CategoryInterface class so we do not have to deal with the implementation class directly.

[laoneo]

I need to get this one merged to finish the service conversion of com_contact, com_newsfeeds and com_categories.

[infograf768]

I have tested this item ✅ successfully on 582fa3e

This PR here does not break more than is already broken (specially when concerning multilang routing in frontend (info-block).

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20693.}

[Hackwar]

I don't really want to name this CategoriesInterface. The whole category system is a tree implementation, which is why I implemented a node interface here: #21327 I don't know how to name it in the tree-object-sense, but maybe use something that more aligns with tree terminology, instead of focusing heavily on the categories stuff. In an ideal world, JMenu would implement the same interface and menu items become a NodeInterface object, too.

[laoneo]

I agree for the tree, but the object which returns the tree is category related. So it makes sense to name it CategoryInterface. The implementation class should probably being renamed.

[wilsonge]

Technically this is a b/c break for people who are subclassing JCategories and overriding this method.

Having said that I doubt people are overriding this method so it's probably ok. any thoughts?

[laoneo]

Agree, lets revert it then.

[wilsonge]

Do we really want this in the interface? I think the options setting is specific to the implementation?

[laoneo]

In the router you get a Category Injected and then you want to fetch the children with access check and without, so we need it there, or we inject there then the factory.

[laoneo]

Can we get this merged @wilsonge so I can finish the service provider story?

[wilsonge]

I know it's annoyingly retrospective. But this looks good to me.