[Proposal]: Implementation specific documentation

# Implementation specific documentation

* [x] Proposed
* [ ] Prototype: Not Started
* [ ] Implementation: Not Started
* [ ] Specification: Not Started

## Summary
[summary]: #summary

In LDM, we've wanted to be precise and complete on the behavior of new features. This means that feature speclets often include more implementation details than we might want in the official language specification. We want a roadmap for ourselves to document this behavior, and guidelines on what should be in the language specification vs. roslyn-specific documents.

For example, the [roslyn](https://github.com/dotnet/roslyn) repo already includes a document for [Specification deviations](https://github.com/dotnet/roslyn/blob/main/docs/compilers/CSharp/Deviations%20from%20Standard.md).

## Motivation
[motivation]: #motivation

We want to clearly define all supported behavior, but we also want to keep the language specification "clean" regarding many implementation details.

## Detailed design
[design]: #detailed-design

There should be four different documents in the roslyn repo, and the published on [Microsoft Learn](https://learn.microsoft.com/dotnet/csharp) in the language specification area. Most are required in the section of the specification on [Portability issues](https://learn.microsoft.com/dotnet/csharp/language-reference/language-specification/portability-issues#annex-b-portability-issues)

- The existing [Specification deviations](https://github.com/dotnet/roslyn/blob/main/docs/compilers/CSharp/Deviations%20from%20Standard.md) document. This document describes roslyn-specific compiler behavior that deviates from normative language in the [C# language specification](https://learn.microsoft.com/dotnet/csharp/language-reference/language-specification/readme). Note that this document is incomplete.
- An article that describes [Implementation defined behavior](https://learn.microsoft.com/dotnet/csharp/language-reference/language-specification/portability-issues#b3-implementation-defined-behavior). The specification defines a number of behaviors that should be defined for the roslyn implementation. We don't have that article at this time.
- An article that describes behavior supported by roslyn, where the language specification doesn't require certain behavior. An example is that roslyn now defines `1` as the value of a `bool` that is `true`. The language specification only requires a value be "distinct from zero.".
- An article that describes any behavior defined by roslyn where the language specification leaves the behavior as [undefined](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/portability-issues#b4-unspecified-behavior). This could be combined with the previous article.

## Drawbacks
[drawbacks]: #drawbacks

It is more work.

## Alternatives
[alternatives]: #alternatives

We could require all the implementation behavior to be part of the language specification.

## Unresolved questions
[unresolved]: #unresolved-questions

What behaviors that aren't required by the standard are supported by roslyn?

## Design meetings

This issue was raised on Jan 31. Notes aren't yet available.