Bug / Deficiency: get_sharing_group by name does NOT function as intended with "name" searches instead of ID/UUID searches

The get_sharing_group function in PyMISP objects seems to not function as intended when searching by strings.

In an instance, we have a sharing group that is titled exactly "Tor Nodes Data". The get_sharing_group object suggests that it might be possible to use a sharing group name to get the sharing group by text search as such:

misp.get_sharing_group("Tor Nodes Data")

However, this returns a hard error when passed to the MISP API backend:

Something went wrong (405): {'name': 'Sharing group doesn't exist or you do not have permission to access it.', 'message': 'Sharing group doesn't exist or you do not have permission to access it.', 'url': '/sharing_groups/view/Tor%20Nodes%20Data'}

This suggests that abstract search of this form does not work. If this is not a usable search mechanism, it will not be easy/trivial to get data out from what sharing group(s) a user is part of in order to use it for filtration in a misp.search call later.

The only way I've discovered as a work around to do this would be akin to this:

def get_sharing_group(groupname: str):
    groups = misp.sharing_groups(pythonify=True)
    for group in groups:
        if group.name.lower() == groupname.lower():
            return group
    return None

It seems this type of search functionality should be part of get_sharing_group if we're accepting abstract strings in the code.

Start at the PyMISP get_sharing_group entry point and reproduce the name lookup using the documented "Tor Nodes Data" example. Compare its behavior with sharing_groups(pythonify=True); done means a valid sharing-group name can be resolved as intended and the existing ID/UUID lookups remain usable.