refactor(select): decouple hlm from brn

[alexciesielski]

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] The commit message follows our guidelines: https://github.com/goetzrobin/spartan/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [ ] Feature
• [ ] Code style update (formatting, local variables)
• [x] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Documentation content changes
• [ ] Other... Please describe:

Which package are you modifying?

• [ ] accordion
• [ ] alert
• [ ] alert-dialog
• [ ] aspect-ratio
• [ ] avatar
• [ ] badge
• [ ] button
• [ ] calendar
• [ ] card
• [ ] checkbox
• [ ] collapsible
• [ ] combobox
• [ ] command
• [ ] context-menu
• [ ] data-table
• [ ] date-picker
• [ ] dialog
• [ ] dropdown-menu
• [ ] hover-card
• [ ] icon
• [ ] input
• [ ] label
• [ ] menubar
• [ ] navigation-menu
• [ ] pagination
• [ ] popover
• [ ] progress
• [ ] radio-group
• [ ] scroll-area
• [x] select
• [ ] separator
• [ ] sheet
• [ ] skeleton
• [ ] slider
• [ ] sonner
• [ ] spinner
• [ ] switch
• [ ] table
• [ ] tabs
• [ ] textarea
• [ ] toast
• [ ] toggle
• [ ] tooltip
• [ ] typography

What is the current behavior?

Closes #252

What is the new behavior?

Decouple hlm from brn. There should be no mention of hlm inside brn. Otherwise it would be a logical circularity.

I think that brn in general should contain no components, otherwise it is taking away control over the final component library from developers.

IMHO, brn should be a set of directives and helpers to build up a component library - something along the lines of a cdk. I think that less logic in brn and more logic in hlm is a good thing as it gives developers the most control. But is also more error-prone in case of future updates. Not sure what the best course of action here is, alhtough I tend to think that more code in developer's codebases is a good thing (because it gives more control).

Anyway back to the PR:

What I'm unhappy about with the current solution is the fact that I had to make updateArrowDisplay an async function because it needs to access the viewport ElementRef, which is now passed to the directive through a signal.

Happy to hear suggestions for a cleaner solution for this.

In general I tried to leave as much code as possible inside the brn directives, although again I'm wondering how much UI-related logic should live inside brn (again, imho, none or as little as necessary - although I'm having trouble defining what necessary in this case means).

Also, I didn't touch the tests and generators yet. Once we're happy with the changes I will get to it, too.

Does this PR introduce a breaking change?

• [ ] Yes
• [ ] No
• [x] hlm components need to be regenerated, but otherwise the API stays the same (as long as brn isn't mentioned in the final code)

Other information

[thatsamsonkid]

Sorry, figured I would move this to the issue discussion, seemed more appropriate! #252