* <!-- PLEASE READ THE FOLLOWING INSTRUCTIONS -->
<!-- DO NOT REBUILD THE CSS OUTPUT IN YOUR PR -->
<!-- Choose one of the following: -->
This is a bugfix
<!-- New feature? Update the CHANGELOG.md too, and eventually the Docs. -->
<!-- Improvement? Explain how and why. -->
<!-- Bugfix? Reference that issue as well. -->
If a form field is disabled and that form field uses has add-on element ( has-addons ), hover state is overlapping to add-on element.
### Proposed solution
<!-- Which specific problem does this PR solve and how? -->
<!-- If it fixes a particular Issue, add "Fixes #ISSUE_NUMBER" in your title -->
This solution excludes disabled form elements hover state which is used within has-addons fields wrapper.
Fixes#1992
### Tradeoffs
<!-- What are the drawbacks of this solution? Are there alternative ones? -->
<!-- Think of performance, build time, usability, complexity, coupling…) -->
No tradeoffs.
### Testing Done
I checkout out master and changed the lines.
* Disabled form elements hover state is overlapping, if control has add-ons elements
If a form field is disabled and that form field uses has add-on element ( has-addons ), hover state is overlapping to add-on element.
* Disabled form elements hover state is overlapping, if control has add-ons elements
If a form field is disabled and that form field uses has add-on element ( has-addons ), hover state is overlapping to add-on element.
Corrects the problem of the .has-icon-left / .has-icon-right fields floating out of the input area when a .help element is floated to the right of a preceding input
Resolves an issue where compiling the sass resulted in `error (Line 348 of bower_components/bulma/sass/elements/form.sass: The line was indented 2 levels deeper than the previous line.)`.
