### Context
By default, Objective-C code will only perform availability checks for iOS APIs introduced from iOS 11 and up. We can enable -Wunguarded-availability to turn on available checks for older SDKs.
Additional context for this behavior comes from [llvm](https://reviews.llvm.org/D34264);
> [This patch](https://reviews.llvm.org/D34264) adds a new warning flag called -Wunguarded-availability-new. If -Wunguarded-availability is off, this warning only warns about uses of APIs that have been introduced in macOS >= 10.13, iOS >= 11, watchOS >= 4 and tvOS >= 11. This warning is on by default. We decided to use this kind of solution as we didn't want to turn on -Wunguarded-availability by default, as we didn't want our users to get warnings about uses of old APIs in their existing projects.
### What's happening in this change
This change turns on -Wunguarded-availability. This has the effect of the compiler performing availability checks for all APIs at or above the current deployment target (iOS 8.0). As such, this PR addresses several instances of code that were not performing availability checks.
Going forward, we will be able to use availability to encode our supported SDKs into the APIs that we provide. For example, we could annotate MDCActivityIndicator with NS_AVAILABLE_IOS(9_0) and all of our code would then have to use runtime checks prior to using this API.
### Caveats
Because -Wunguarded-availability is not enabled by default in Objective-C, our clients will need to proactively enable this flag in order to be warned of any use of APIs that support OS versions < 11.0. We can mitigate this risk in two ways:
1. Clearly announce any changes in our supported OS versions.
2. Encourage clients to enable -Wunguarded-availability.
[TextFields] Updates to SimpleTextFIeld and InputChipView prototype
This PR contains a lot of updates to SimpleTextField. Some of these updates are for little things I noticed I got wrong after looking at the guidelines a bit more. The more substantial changes introduced here, however, are related to feedback given in the design doc overview meeting in January. As a reminder, the two takeaways from that meeting were:
1. SimpleTextField shouldn't depend on MDCContainerScheme
2. The styles should not be represented as enum cases. Instead, they should be objects.
These changes address those pieces of feedback. While I still need to get around to updating the design doc to reflect the changes, I don't see the harm in merging the updates into their home in a MaterialComponentsExamples experimental directory.
This PR also contains changes that are not directly related to SimpleTextField!
Late last year, when we had the week of free time to do whatever we wanted, I began thinking about incorporating chips into SimpleTextFields. Not far into it I decided that any view implementing input chip functionality should be its own view, i.e. it shouldn't be stuffed in a UITextField, which carries inheritance-related burden. I started work on such a view in January, and briefly used it during the SimpleTextField design doc overview meeting to demonstrate how SimpleTextField styling could be generalized across views.
Following that meeting, and following the refactoring work to address feedback on SimpleTextFields, I updated the InputChipView to see how extensible my "container style as object" approach was. I think the work here, while definitely not a finished product, demonstrates that it's fairly usable. MDCSimpleTextField (I added an MDC) and InputChipView (no MDC) both conform to a protocol called MDCContainedInputView. That protocol declares a property for objects conforming to MDCContainerStyling. There are a few other classes and protocols in there, but I will write or talk more about those in a different setting. The key here is that I think it all might work, based off these changes. There are still some loose ends, but they can be taken care of. They _will_ be taken care of if the team decides to take this direction. They maybe won't if we decide to continue investing in MDCTextFields for all of our user input needs. If we do end up deciding to bring all this into the codebase I want the next addition to this family of contained input views to be a subclass of UITextView, for multiline text input.
This gif shows the updated MDCSimpleTextField styled as an "outlined" text field:
This gif shows the updated MDCSimpleTextField styled as a "filled" text field:
This gif shows the updated InputChipView styled as an "outlined" input chip view whose chips do not wrap:
This gif shows the updated InputChipView styled as an "outlined" input chip view whose chips wrap:
This gif shows the updated InputChipView styled as a "filled" input chip view whose chips do not wrap:
This gif shows the updated InputChipView styled as a "filled" input chip view whose chips wrap:
Removes the need to copy-paste stanzas from other files anymore as we'll rely on #4478 to generate the correct stanza for us instead.
This was an automated change generated by running a find-and-replace regular expression:
```
/\*
Copyright ([0-9]+)-present the Material Components for iOS authors\. All Rights Reserved\.
Licensed under the Apache License, Version 2\.0 \(the "License"\);
you may not use this file except in compliance with the License\.
You may obtain a copy of the License at
http://www\.apache\.org/licenses/LICENSE-2\.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied\.
See the License for the specific language governing permissions and
limitations under the License\.
\*/
```
```
/\*
Copyright ([0-9]+)-present the Material Components for iOS authors\. All Rights Reserved\.
Licensed under the Apache License, Version 2\.0 \(the "License"\);
you may not use this file except in compliance with the License\.
You may obtain a copy of the License at
http://www\.apache\.org/licenses/LICENSE-2\.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied\.
See the License for the specific language governing permissions and
limitations under the License\.
\*/
```
```
/\*
Copyright ([0-9]+)-present the Material Components for iOS authors\. All Rights Reserved\.
Licensed under the Apache License, Version 2\.0 \(the "License"\);
you may not use this file except in compliance with the License\.
You may obtain a copy of the License at
http://www\.apache\.org/licenses/LICENSE-2\.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied\.
See the License for the specific language governing permissions and
limitations under the License\.
\*/
```
```
// Copyright $1-present the Material Components for iOS authors. All Rights Reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
```
We can now make use of @available throughout our codebase.
We support Xcode 9 and up, which includes the iOS 11 SDK. This means we can remove any guards for SDKs prior to iOS 11.
This was cleaned up by running a global find-and-replace with the following regular expression:
```
Find:#if defined\(__IPHONE_11_0\) && \(__IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_11_0\)\n(.+if \(@available\(iOS 11.0, \*\)\) \{(?:.|\n)*?)(?:#else(?:.|\n)*?)?\n#endif
Replace:$1
```
With some additional cleanup for stragglers that didn't match this pattern. Note that else clauses were intentionally dropped.
Closes https://github.com/material-components/material-components-ios/issues/4909
