fix: Search filters returned all possible options, not just values for which user had permissions

[bencap]

This pull request adds permission checks to score sets when generating filter options to ensure users can only see filters for which they have permissions to read. To support this change and prevent circular imports, it also refactors the handling of the UserData type throughout the codebase.

Score set search filter logic update:

• Updated the signature of fetch_score_set_search_filter_options in src/mavedb/lib/score_sets.py to accept a requester parameter of type UserData, and added per-score-set permission checks to ensure only permitted score sets are included in the filter options. ([1], [2])
• Added performance notes and suggestions for future optimization in the score set filter construction loop. (src/mavedb/lib/score_sets.pyL301-R335)

Type definition refactoring:

• Moved the definition of the UserData dataclass from src/mavedb/lib/authentication.py to a new module, src/mavedb/lib/types/authentication.py, and removed its previous definition. ([1], [2])
• Updated all imports of UserData in various files (including authorization, permissions, experiments, routers, and utilities) to reference src/mavedb/lib/types/authentication.py instead of src/mavedb/lib/authentication.py. ([1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23])

[jstone-dev]

This looks good. On my local, it takes <2 seconds to load the options now that we're filtering on access to score sets. Given reasonable expectations about growth in the number of score sets, I think this will be okay for a good while, but I agree with the options for optimizing it should we need to.