Ellipsis are now appended after the length limit is hit, rather than
before.  Since API consumers might want to compensate for the width of the
ellipsis, it is now exposed as a print option.

Per our offline discussion, `ObjectFormatter` is pretty heavyweight and
most users will only want to tweak simple switches (e.g. hex vs decimal).

I'm still thinking about the best way to address the advanced scenario, in
particular, how to allow multiple hooking of composite (i.e. non-primitive)
object formatting.  In the meantime, here's an API that should be usable
in core scenarios.

TODO: existing tests pass, but I need to add new ones.

...and a host object property on InteractiveScriptGlobals.

This is a first cut and my main goal at this point is forward
compatibility.  The existing unit tests all pass.

TODO: Make some improvements to the existing behavior.
TODO: Update the existing test baselines.
TODO: Introduce new tests.

This branch should be buddy testable - tweak the existing formatter by
subtyping (e.g.) `CSharpObjectFormatter` and assigning an instance of your
subtype to the global `ObjectFormatter` property.  It should be consumed
by subsequent submissions.

Bug Fix 5607: VB Parenthesis overtyping

Pass Version46 to ToolLocationHelper to find default.win32manifest

The bug was that automatic brace completion will not overtype close
parenthesis if the close parenthesis token was preceded by a numeric
literal. The bug was in `IsEntirelyWithinStringOrCharOrNumericLiteral`,
where we were imposing checks meant for chars and strings on numeric
literals, which was likely introduced in PR #1763. This change addresses
it by not enforcing checks meant for chars/strings on numeric literals.

pull-request-bot comments on the PR asking for dotnet-bot to run VSI tests

fix test failures caused by localization

Cleanup WorkItem Attribute

Correctly identify if we are in a static property.
Fixes #8010

Manually inspected the WorkItem values and added the appropriate URL.

Handled all WorkItem instances that refer to migrated work items.

We are choosing to pass Version46 instead of VersionLatest.
TargetDotNetFrameworkVersion is an enum, and VersionLatest is not some
sentinel value but rather a constant that is equal to the highest
version defined in the enum. Enum values, being constants, are baked
into consuming assembly, so specifying VersionLatest means not the
latest version wherever this code is running, but rather the latest
version of the framework according to the reference assembly with which
this assembly was built. As of this writing, we are building our bits on
machines with Visual Studio 2015 that know about 4.6.1, so specifying
VersionLatest would bake in the enum value for 4.6.1. But we need to run
on machines with MSBuild that only know about Version46 (and no higher),
so VersionLatest will fail there.  Explicitly passing Version46 prevents
this problem.

Correct fallback pathToTool in build task and print more info in log

don't assume a file uri is absolute

[WIP] Temporarily disable crossgen

Add culture dependant object formatting in REPL

made diagnostic tags to be removed faster and inserted slower.

made VS to automatically disable full solution analysis if we detect …

Update Object display to use CurrentUICulture.
Ensure that VB tests run.

Add a "Test" target that can be used to test an xunit project

Update restore.ps1 to use WebClient.DownloadFile

Update SRM to 1.2.0-rc3-23721

Correctly detect existing constructors during code generation

wget (alias for Invoke-WebRequest) attempts to update the powershell UI for every byte downloaded, which is very slow. Changing this to use WebClient.DownloadFile avoids this penalty and speeds up the download process significantly.

use DebugType settings from VSL.Settings.targets