inline in template boolean literals

[titoBouzout]

This change, inlines in the template boolean literals. For example

<el attr={true}/> becomes <el attr/>
and
<el attr={false}/> becomes <el/>

Considerations:

• this change skips doing this transformation for "custom elements", because as we are defaulting to properties I suspect something will break.
• I do not think this is a breaking change, at least from my tests I didn't see anything that could cause problems.
• this is related to an effort to fix the attributes vs properties problem

The most recent issue illustrating this props vs attr problem comes from #384 In there they are doing <video playsinline={true} />;, in production code currently:

• client side works because compiles it to _el$.playsInline = true;
• in ssr is inlined in the template
• ssr with hydration fails because it tries to add the property with the lowercase name as _$setProperty(_el$, "playsinline", true);

With this change,

• boolean attributes will always be inlined for the true case and skipped for the false case
• once the pr with the types gets merged it will only accept "true" | boolean, so trying to do `"false"`` as a string should be a type error

I am hoping before solid 2.0 we can get rid of the hardcoded list of properties

Thanks!

[ryansolid]

The thing is the playsinline probably should be mapped properly anything that is denoted as a property should have translation for attributes. We just missed this one. That being said the other change is probably beneficial anyway.

Like to be clear. It is very intentional to use the properties for booleans and if we are to be able to set them as attributes as well then there is no way to get rid of the lookup.

Only question here is does this PR consider the fake booleans? Like things that need to be string "false" vs "true" where the application of just the property being there doesn't work. We have the constants list to differentiate between those.