ApiCompatibility Symbol filtering story is incomplete

[safern]

We are missing Attribute filtering and some scenarios in the accessibility filter, see: #16817 (comment)

For Attribute filtering I think it makes sense to have a filter dedicated to it that ignores compiler generated attributes and a default list of attributes that shouldn't contribute to API Compatibility like EditorBrowsableAttribute. Also it should be able to take a list of attributes to ignore based on user settings.

cc: @ericstj @Anipik

[ViktorHofer]

@ericstj regarding your comment:

Take note of this scenario: https://github.com/dotnet/arcade/blob/3dd26504b456b68c2e3edd18ebf159d0b5486135/src/Microsoft.Cci.Extensions/Filters/PublicOnlyCciFilter.cs#L55-L66
Maybe those are other filters but they did matter for our existing API compat and GenAPI analysis.

I did take a look to check if we are unintentionally excluding API that should be checked. In the example above, the filter checks if a member is not public but abstract and is part of a public abstract type. At least for C# the compiler emits an error as "virtual or abstract members cannot be private":

I would also need to check if the same is true for VB and F# but at least just for C# this logic doesn't seem to be necessary.