refactor(select): decouple hlm from brn

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)

goetzrobin / spartan