Merge misc. changes for embedded attributes from 7a0467ec

Fixes an issue with flow analysis where branches within `try` could be considered as going through `finally`

Use synthesized attribute infrastructure for System.NullableAttribute

Misc.

Misc.

Misc.

Misc.

Misc.

Misc.

PR feedback

Override in PEMethodSymbol

Merge master to post-dev15.5-contrib

Create build.sh

Reuse proxy fields in async state machine

* Marshalling methods with `in` parameters should have [In] attribute

* Apply [In] on all `in` parameters

* More tests

* nit

Also skip another test that failed while skipping the original test

Ensure CodeModel adds elastic trivia when setting names

Currently, full signing is always disabled on Linux/Mac because it was
not supported. Now, it is supported. To avoid taking a dependency on
full signing, this only enables full signing when we're confirmed to be
building with a bootstrap compiler.

Fix NullReferenceException thrown while building IOperation node for dynamic object member initializer. (#23162)

Fixes #23154.

Related to #22548 and #22229.

Do not expose operation nodes for BoundRangeVariables in C# query exp…

Related to #22548 and #22229.

There are several issues with IOperation tree when it comes to conversions applied to tuple literals:
1. When conversion is explicitly specified in code, it is translated to conversions on individual
elements of the literal and these BoundConversion nodes are also marked as explicitly
specified in code (which makes sense). However, the syntax associated with a BoundConversion
node on top of an element matches the syntax of the element (which also makes sense).
The problem is that both the conversion node and the element appear as “explicit” in
IOperation tree, which violates one of the tree invariants – at most one “explicit” node for
a given syntax node.
2. When a tuple literal is converted, compiler creates a BoundConvertedTupleLiteral node,
which has the target tuple type as its Type, but the BoundConversion node on top of the
BoundConvertedTupleLiteral captures conversion information (kind, etc.) for conversion
From tuple’s natural type to the target type. So, often, we end up with both nodes having
The same Type, but the conversion says it is not an identity conversion. This shape helps
SemanticModel to provide accurate information about types and conversions, but the
IOperation tree looks very confusing.
3. When conversion is explicitly specified in code, the BoundConversion node from the
previous item is marked as explicitly specified in code, but it shares syntax node with
BoundConvertedTupleLiteral. Both nodes appear as “explicit” in IOperation tree, which
violates the same invariant.
4. When conversion is explicitly specified in code, compiler adds yet another explicit
Identity conversion on top of the BoundConversion node from the previous item.
It is needed for proper SemanticModel behavior. Even when it uses different syntax,
the IOperation tree looks very confusing, there are two conversions on top of each other
and it is not clear why intermediate conversion node is needed.

In order to address all these issue the following changes are made to IOperation factory:
- If conversion node is associated with the same syntax as its operand, the conversion
is marked as isImplicit.
- If Type of BoundConvertedTupleLiteral matches the Type of BoundConversion node
on top of it the conversion node is not added to the IOperation tree. Instead a new property
is added to ITupleOperation interface, called NaturalType. The property exposes the natural
type of the tuple literal and makes it easy for consumers to figure out if a conversion from
a natural type of a tuple literal took place.
-  If Type of BoundConvertedTupleLiteral doesn’t match the Type of BoundConversion node
on top of it and there is an identity conversion node on top of the BoundConversion node,
the intermediate conversion node is not added to the IOperation tree, its conversion
information is used for the top-most conversion node (instead of saying that it is identity).

Reduce the use of the preprocessor

    Fixes an issue with flow analysis where branches within `try` could be considered as going through `finally`

    We could incorrectly assume that variable is assigned (or unassigned in async capture tracking case).

    As a resutl we could
    - allow use of unassigned locals (undefined behavior)
    - not capture a local whose value survives `await` (NRE crash)

    Also added a regression test fro VB, which does not seem affected.

    Fixes:#19831

Address followup nits from IOp prs.

Replace Windows RID multitargeting with singular form

Do not offer 'var' if it would cause overload resolution issues.

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/512823

In VB Code Model, we use SyntaxFactory.ParseTypeName/ParseName when
setting the name of an attribute or namespace. Doing this fails to add
elastic trivia the way it is added in all other cases, so setting the
name of a namespace (for example) would remove the newline, creating
broken code. To fix this, we now manually add elastic trivia in these
cases.

C# was already functioning correctly, but it was using
".IdentifierName()" to parse dotted names, which isn't advised. This
change also updates the C# side accordingly.

* Separating warning messages for constant filter expression
* Deal with try-catch with finally block and add test

Use all RIDs on all platforms

Add the Roslyn version string into Help > About

Disable 'use local function' in a few important language cases.

RunCore previously had a mix of diagnostic reporting methods including
lists of Diagnostics, lists of DiagnosticInfos, ConcurrentQueues of
Diagnostics, and just printing things directly to the console. This
commit tries to simplify things by moving to using Diagnostics and
DiagnosticBags wherever possible in the compile+emit phase of RunCore.