chore: migrate from deptrac to structarmed

[samsonasik]

Description

This PR try to migrate deptrac to structarmed, the vendor parts seems no need to be included in layer definition, structarmed treats dependencies on classes that don't match any defined layer as external/unregistered and automatically allows them, and src/Views/ contains only PHP template files with no class or namespace declarations, so no PHP class would ever match a View layer pattern regardless

Let me know if there is a catch so I can improve in structarmed first itself if possible.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[samsonasik]

Ready for review/merge 👍

[samsonasik]

@datamweb review applied 👍

[datamweb]

structarmed treats dependencies on classes that don't match any defined layer as external/unregistered and automatically allows them

Since structarmed allows all unregistered classes by default, it seems the only way to forbid vendor usage in a specific layer is to explicitly register those vendor namespaces via layerPattern(), and then omit them from the ruleset.
Is registering vendors as layers the recommended approach in structarmed to achieve strict boundaries? Or do you plan to add a feature like a strict mode (deny unregistered by default for specific layers)?

[datamweb]

LGTM!

[samsonasik]

@datamweb I think I need a real violation example first for that, eg use of:

new \CodeIgniter\Controller();

on specific part, which not allowed. That will may use MayNotDependOnRule, probably something like:

    ->layer('CI_Vendor_Controller', ....)
    ->rule(
        'entity.must_not_use_ci_controller',
        new MayNotDependOnRule(from: 'Model', to: 'CI_Vendor_Controller')
    )

[samsonasik]

Thank you @datamweb @michalsn , let's merge 👍