1-arg variant of hal_impl_domain

This improves readability and consistency for HAL implementation
domains which have only one implementation.

Test: No change to policy according to sesearch
Test: No change to which types are associated with haldomain according to "sepolicy-analyze <sepolicy file> attribute haldomain"
Bug: 34180936
Change-Id: Ice599ea4971cdfbd8b835b1fd02ad1e14c7a0386

public/hal_allocator.te

 # allocator subsystem
-type hal_allocator, domain, haldomain;
+type hal_allocator, domain;
+hal_impl_domain(hal_allocator)
+
 type hal_allocator_exec, exec_type, file_type;
 
 # hwbinder access

public/hal_boot.te

 # boot_control subsystem
-type hal_boot, domain, boot_control_hal, haldomain;
+type hal_boot, domain, boot_control_hal;
+hal_impl_domain(hal_boot)
+
 type hal_boot_exec, exec_type, file_type;
 
 # hwbinder access

public/te_macros

@@ -116,9 +116,14 @@ typeattribute $1 bluetoothdomain;
 ')
 
 #####################################
-# hal_impl_domain(domain, hal_type_attr)
+# hal_impl_domain(domain[, hal_type_attr])
 # Allow a base set of permissions required for a domain to host a
-# HAL implementation of the specified HAL type.
+# HAL implementation.
+#
+# Optionally, the type of the HAL can be specified as the second
+# argument. This is useful for HALs which may have multiple
+# implementations. Attributes are used to group the various
+# implementations of such HALs.
 #
 # For example, default implementation of Foo HAL:
 #   type hal_foo_default, domain;
@@ -126,7 +131,7 @@ typeattribute $1 bluetoothdomain;
 #
 define(`hal_impl_domain', `
 typeattribute $1 haldomain;
-typeattribute $1 $2;
+ifelse($2, `', `', `typeattribute $1 $2;')
 ')
 
 #####################################