fix: delegate should be set on nativeTextViewProtected

[farfromrefug]

just like textfields. Fixes components extending this one

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/DevelopmentWorkflow.md#running-unit-tests.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/WritingUnitTests.md.

What is the current behavior?

What is the new behavior?

Fixes/Implements/Closes #[Issue Number].

[NathanaelA]

Interesting -- I have to be honest, having nativeTextViewProtected confuses me, and I was thinking maybe either something legacy, or potentially a extended class might have it own separate nativeTextViewProtected.

So I just scanned the entire NS source code for nativeTextViewProtected to see if their is somewhere that this is actually using a variable and not just the textbase.getter. It is used 178 times in the code; however ALL of them extend text-base-common so they all are using the getter that returns nativeViewProtected as the value that is being changed.

It is used in:
Label, editable-text-base, text-view, text-field, and finally text-base. However all of them extend text-base; which is where they get access to the getter nativeTextViewProtected which is just a getter that returns nativeViewProtected

Can anyone think of a good reason to not rename all instances of nativeTextViewProtected back to nativeViewProtected to simplify the codebase? (However leaving the nativeTextViewProtected getter so that we don't break any third party plugin code...)

Please note nativeViewProtected is used by View which is one of the base classes ALL views extend from, so having the name change in a few of the components but be still mapped to the same base value seems confusing to me...

Edit: this comment makes more sense AFTER the review -- it was done after the review; so realize that this is after I made comments on the code changes..

[farfromrefug]

Please dont do that. That was done in a effort with the old N team to make it work with material native plugins where a text field/textview is made of 2 views : the layout and the actual text field. So some properties must be applied to one and some to the other. This brings a lot of flexibility to plugins developers.

By changing that you will break all my material plugins !
That PR simply finishes the work we started with the old team (textview was not in scope at the time)

[farfromrefug]

I told you it helps in separating what should be applied to the textview and what should be applied to the layout.

And of course you will break plugins if you remove it !
btw this PR / fix is needed to fix issue users are having because the textview is not behaving as the text field.

[farfromrefug]

Really bold, uppercase? Seriously....

It fixes delegate being set on the wrong view on iOS (the layout and not the view).if
I can't show code it fixes in my comp.as it is not code in my comp but in N. For.my comp nativeViewProtected and nativeTextViewProtected are different. Before this PR the delegate for UITextView was set on the "layout" view (represented by nativeViewProtected)
You should read this
#6102
#8514
EDIT: it does fix an issue in N. In the approach used in N with nativeTextViewProtected, the delegate was set on the wrong view. No "visual side effect" in N ui but the code is wrong and breaks plugins based on this

[NathanaelA]

Based on the code Igor linked me to; I believe this is a valid use case to eliminate extra work on the plugin author without being a major issue for the framework. We do need to document this getter and we created a PR #8886 and any comments would be helpful