* Remove lots of duplicated code
* Add support for testing external code elements

Fixes #6002

Essentially, the problem is that the type character should never be considered as part of the parameter name. This was happening in two places:

1. Comparison of parameter names in code model events. Because the type character was being included, a Rename event would be incorrectly triggered.
2. ICodeModelService.GetName(...) incorrectly returned the type character for parameters. This resulted in downstream effects of not being able to look up the CodeElement for a node by name.

Fixes #5868
Fixes #5841

* Added another "stress" test that performs 100 operations to catch failures in the element table.
* Addressed problem where CleanableWeakComHandleTable.TryGetValue() might incorrectly return true.
* Fixed issue in FileCodeModel.GetOrCreateCodeElement() where a node key might not be removed from the element table.
* Unskip tests

Related to #5841.

See #5800 for a report of the broken tests.

Specify correct ComDefaultInterface for EnvDTE.CodeClass, fixing the results of System.ComponentModel.TypeDescriptor.GetProperties(...)

In Visual Studio 2013, CodeFunction.Name for C# conversion operators listed the "implicit/explicit" keyword first and the "operator" keyword second. In Visual Studio 2015, we accidentally swapped these. Unfortunately the v1 Workflow Designer depends on this value and the change broke scenarios where conversion operators are used. That change fixes that discrepancy and adds more unit tests around FullName and Name for operators.

Properly specify the round-trip format specifiers for floats and doubles in IMethodXML (used by WinForms)

This is a fairly involved issue that can manifest in a number of ways.
Currently, the only known scenario where this is exposed within VS is
the "Convert to Web Application" command but there are certainly others
and customers using Code Model could easily run into it.

The scenario is essentially this:

* In Code Model, grab and hold a reference to a code model object for
some container element.
* Access a certain type of child element parented by that container. In
particular, a property accessor, an event accessor, an attribute, an
attribute argument, a VB Inherits statement, a VB Implements statement,
or using directive/Imports statement.
* Try to access a property on the container reference in step 1.
* Exception gets thrown!

Understanding why this happens will require understanding a few of the
system concepts underlying Code Model.

First, Code Model elements tend to have long lifetimes that live through
file edits and even renames. For example, one could grab a reference to
an ```EnvDTE.CodeClass``` and hold onto it. As the user makes edits to
the file containing that class the class element should continute to be
valid (until the user makes an edit that breaks it). Since their
lifetimes can be potentially long, Code Model elements hold onto "node
keys" rather than the SyntaxTree nodes, which they use to get back to
their underlying node in the source file.

Node keys have a very simple format. Essentially, they are the "name" of
the node (qualified syntactically) along with an ordinal which allows
there to be multiple nodes with the same name. Consider the following
code:

```C#
namespace N
{
partial class C
{
void M() { }
}

partial class C
{
}
}
```

In the code above, there are four potential Code Model elements with the
following node keys:

* N, 1
* N.C, 1
* N.C.M, 1
* N.C, 2

Second, some Code Model elements don't actually have node keys. These
are objects that are parented by other code model objects. For example,
parameters are parented within a method or propery, property accessors
are parented within a property, etc. These "keyless" objects can be a
bit tricky because they need to hold a reference to their parent object.

Third, each FileCodeModel maintains a cache of Code Model elements using
their node keys. Whenever a Code Model element is going to be created
for a particular node key, the FileCodeModel first checks to see an
element already exists. If so, it returns the cached element instead.

With that background, here's what's happening:

In several cases, creating a parented keyless Code Model element was
skipping the lookup in the FileCodeModel's cache when creating it's
parent. So, if an element represent the parent already existed in the
cache, a second Code Model element would be created for the same node.
This gets ugly because the process creating a Code Model element causes
it to be added to the FileCodeModel's cache. So, there is an attempt to
add the newly created Code Model element when there's already one
present in the cache with the same node key.

Ideally, this situation would have thrown an exception. However, when
there's a collision, there's a code path in the FileCodeModel's cache
that tries to find a free slot in the cache by changing the original of
the element's node key. This code is super-suspicious and is, quite
honestly, probably wrong. However, removing it is a risky at this point.
So, I'll look at cleaning this up in the master branch.

For now, I've audited all of the places where a parented keyless Code
Model element constructs its parent and ensures that it goes through the
FileCodeModel's lookup.