[BUGFIX] Adds the ability to blacklist props that should use setAttribute because of browser compliance issues

[jayphelps]

fixes emberjs/ember.js#11112 and sets the stage for #353 which is the same code-path and desired outcome but different cause.

[jayphelps]

Added another test.

[jayphelps]

Amended with input#type as well, so we can revert emberjs/ember.js#10690 and get more natural behavior in that case (the attr value will still be the invalid type, as expected, instead of text)

[rwjblue]

Seems good to me.

@mixonic can you review and 👍 / 👎?

[jayphelps]

@mixonic ping

[rwjblue]

@mixonic / @mmun - Do either of you have objections? Will merge and release tonight if I don't hear otherwise....

[stefanpenner]

we should add the form attribute for the appropriate tags aswell. Essentially merging this PR and https://github.com/tildeio/htmlbars/pull/352/files

[mmun]

Seems fine.

[jayphelps]

@stefanpenner I would prefer #353 since it covers more than just the form attribute case. I plan to rebase once this is merged. Thoughts?

[stefanpenner]

@jayphelps yes i believe so, although i don't believe it handles the type case. Or am i wrong?

[jayphelps]

@stefanpenner It does not. Sorry if this is confusing. This PR handles specific cases of type for both input and button, #353 handles the form attribute in a generic way. They're in the same code path but the cause and solution of each are separate.

[jayphelps]

@stefanpenner Although we could use this PR's blacklist method for form, I don't think we should because there are other cases like form that can exist in the wild, especially with w3c web components. This PR handles non-compliance to spec, where as #353 handles non-writable behaviors, regardless of whether or not it is because of compliance. i.e. I think we need both.