web-twig: boolprop filter refactor + introduce typing

[literat]

WHEN (situation): I use boolprop filter in components,
WHAT: I want the implementation to be correct according to the technical requirements currently imposed on PHP implementations,
WHY: because it is not correct to use type cast and thus should be avoided.

Acceptance criteria
we have refactored the boolprop filter according to the technical requirements or we don't use it at all and have another solution
we don't use string to boolean conversion
we only pass bool parameters using twig syntax, i.e. isHidden={true} is ok, isHidden="true" is wrong
we have pseudo-type filters, i.e. numberType, booleanType, stringType, emotionColorType, etc...; these filters throw an exception/error if a different value is received than it should
Implementation notes (optional)
https://lmccz.slack.com/archives/C01HA3T2D96/p1673007611394419
https://lmccz.slack.com/archives/C02MZ3PNGCB/p1657545449803109
ideally we want to work internally with the bool value in the component implementation, working better with conditions than in the case of string matching
ideally, the component should only accept true/false values and nothing else
mark boolprop filter as deprecated or change its behavior to throw an error instead of converting
implement additional filters to create a pseudo-type system for checking props
numberprop
stringprop
emotionColorProp
actionColorProp
etc...

implement an extension function that will log an error or throw an exception for the type, similar to deprecated
and sensitive filters can then use that function or simply throw an exception
Can dictionaries be configured in yaml spirit-web-twig? Yes they can, we can load the configuration just like twigx-bundle does

https://github.com/lmc-eu/twigx-bundle#step-3-optional
https://github.com/lmc-eu/twigx-bundle/blob/main/src/DependencyInjection/Configuration.php
if the yaml configuration is between design tokens, it should probably not be a problem to import it in the project - https://symfony.com/doc/current/service_container/import.html#importing-configuration-with-imports
What if the dictionaries were tokens? They can extend individual products, they have control over the designers. Export as JSON, JS Object...?