Consider removing IsTrimmable project-level MSBuild property from documentation

Summarizing discussion with @vitek-karas:

`IsTrimmable` (the project-level MSBuild property intended for library authors) has two behaviors:
1. Turns on the analyzer
2. Adds an assembly-level attribute

In the 6.0 timeframe, the default trimming behavior was to trim only those assemblies with the attribute. So `IsTrimmable` was the recommended way for library authors to address trim-compatibility warnings, and to ensure that their libraries would be trimmed by default, so as not to contribute unused code to the app size.

@vitek-karas pointed out that tying the two behaviors together is confusing, because even if a given library is properly trim-annotated, apps which reflect over it may still break when trimmed. In other words, the assembly-level `[AssemblyMetadata ("IsTrimmable", "True")]` doesn't say anything about whether it is "safe" to trim this library in the context of an app that consumes it.

This especially creates problems for scenarios like blazor where trim analysis warnings are off by default, since app authors won't hit these issues until runtime. The model where library authors are guided to put `IsTrimmable` in their project makes it more likely that blazor apps will be broken when consuming such libraries, for example when serializing types from these libraries using trim-incompatible serializers.

@vitek-karas suggested to remove `IsTrimmable` from the public documentation, and instead only recommend turning on the analyzers. Essentially the idea is that the assembly-level attribute should primarily be used by the framework libraries, and we don't want to encourage third-party libraries to use it.