feat: add is_visible callable for dynamic menu item visibility

[ShlomoCode]

from django docs:

django.contrib.auth.models.Group models are a generic way of categorizing users so you can apply permissions, or some other label, to those users. A user can belong to any number of groups.
A user in a group automatically has the permissions granted to that group. For example, if the group Site editors has the permission can_edit_home_page, any user in that group will have that permission.

Beyond permissions, groups are a convenient way to categorize users to give them some label, or extended functionality. For example, you could create a group 'Special users', and you could write code that could, say, give them access to a members-only portion of your site, or send them members-only email messages.

This PR adds support for the groups option as a display condition for a menu item (user_menu/top_menu).
It is very useful in my opinion to be able to control the display option not only based on model permissions but also based on the groups.

It works in the form of AND, if both groups and permissions are defined, and the user has only the groups or only permissions, the item will not be shown to him (open to comments maybe it should work differently).

usage example:

   "topmenu_links": [
        {"name": "Home Page", "url": "home", "groups": ["some_group_name"]},
    ]

[ShlomoCode]

@farridav Can you check this? Thanks

[farridav]

If A user in a group automatically has the permissions granted to that group. then it seems just referencing the appropriate permissions is enough, as the purpose of group memberships is to make permission management easier through inheritence.

Checking group membership as a means of permissions seems to be a bit of an anti-pattern with djangos builtin authentication.

as an example:

• A user with explicit permission "can_view_books" will be able to view the books page
• A user who is member of the "book_viewers" group, that inherits the "can_view_books" permission, can view the books page

The implementation of permission checking need not ever reference groups, as user.has_perm will handle this for you.

To provide a better example, ive added a pull request to demonstrate this in a test: #630

if you feel like something has been lost here, please let me know

[ShlomoCode]

Checking group membership as a means of permissions seems to be a bit of an anti-pattern with djangos builtin authentication.

What do you think about this? https://docs.djangoproject.com/en/4.2/topics/auth/default/#groups:~:text=Beyond%20permissions%2C%20groups,only%20email%20messages

[farridav]

Checking group membership as a means of permissions seems to be a bit of an anti-pattern with djangos builtin authentication.

What do you think about this? https://docs.djangoproject.com/en/4.2/topics/auth/default/#groups:~:text=Beyond%20permissions%2C%20groups,only%20email%20messages

I think its an interesting idea that is something ive never used in that way within Django apps ive built in the past, but i can see the value in it, especially within Jazzmin ;)

That said, i will need you to add tests for this, feel free to borrow from my implementation linked above.

[ShlomoCode]

@farridav Instead of adding explicit groups support, I added an is_visible callable that receives the request object.

This approach is more flexible, users can implement any visibility logic they need (groups with AND/OR, path-based, etc.) without requiring new parameters for each use case.

Also added tests.

[ShlomoCode]

I rsolved the conflicts