Shared interface members accidentally exposed through analyzer public API

[stereotype441]

The following members were accidentally added to the analyzer's public API, by virtue of the fact that some types now mention a shared interface class in their implements clause:

• FunctionType.positionalParameterTypes (exposed via SharedFunctionTypeStructure)
• FunctionType.requiredPositionalParameterCount (exposed via SharedFunctionTypeStructure)
• FunctionType.sortedNamedParameters (exposed via SharedFunctionTypeStructure)
• RecordType.positionalTypes (exposed via SharedRecordTypeStructure)
• RecordType.sortedNamedTypes (exposed via SharedRecordTypeStructure)

After discussing this with @bwilkerson, I've decided to try to address this by:

• Moving the reference to SharedFunctionTypeStructure from the implements clause of FunctionType to the implements clause of FunctionTypeImpl (so that the members of SharedFunctionTypeStructure won't be exposed to analyzer clients using FunctionType)
• Moving the reference to SharedRecordTypeStructure from the implements clause of RecordType to the implements clause of RecordTypeImpl (so that the members of SharedFunctionTypeStructure won't be exposed to analyzer clients using RecordType)

To avoid breaking clients at the time that I make these changes, I'll add deprecated declarations of these members to the FunctionType and RecordType classes. This will ensure that if any analyzer clients have already started depending on these accidentally-exposed members, their code will continue to work, but they'll be alerted to the fact that the members will be removed in the future.

To prevent this sort of problem from cropping up in the future, I intend to change all the analyzer's uses of the shared interface classes in a similar way (e.g., TypeImpl will implement SharedTypeStructure instead of DartType). To make this possible, I'll first need to change the analyzer's use of _fe_analyzer_shared so that when instantiating shared classes, it always does supplies non-public types for the type arguments. (E.g., ResolverVisitor will mix in TypeAnalyzer<TypeImpl, AstNodeImpl, StatementImpl, ...> instead of TypeAnalyzer<DartType, AstNode, Statement, ...>).

I'll post updates here if my plans change.