Refactor built-in policies and how they are exposed

[faern]

Before this PR, the only way to access a built-in policy was via Policy::builtin(name: &str) -> Option<Self>. This provided no compile time guarantee that the policy you tried to use actually existed, and you had to unwrap at runtime to find out. The code also repeated all policy names a bunch of times, which can be error prone and also a bit harder to read.

This PR refactors how the library includes the built in policies and exposes them to library users. Key changes include:

• Keep Policy::builtin(&str) -> Option<&Policy> for usage when the desired policy name is only known at runtime. For example user specified.
• Expose a public static for each built in policy. This allows referring directly to a policy in code and get compile time checks if that policy exists.
• Move actual raw policy files into their own directory, to separate them from the code
• Put built-in policies inside LazyLock to only have to parse them once instead of on each access. But hide the LazyLock from the public API to make it possible to change the implementation later.
• Put everything in a macro, so that adding another policy is a oneliner (plus adding the file with the raw unparsed policy)

[gregoire-mullvad]

Thanks for this. I like that the BuiltinPolicy struct hides the LazyLock.