Changed AnnotatingDiamond example to basically show all of Donggyu's api members as applied to an annotated component
Does this via println

Relative and Absolute have common traits that the annotation value implements

The notion of a pass id has been removed from the annotation system
The value portion of an annotation is now a subclass of an AnnotationValue trait
TODO: Consider Adding Scope information as traits

Create new Annotation object which is a container for new annotation classes and functionality
Add annotate method to Module
Add Optional annotation parameter to Circuit case class, default is empty Seq
Add Annotaion ArrayBuffer to Dynamic Context, Builder.build will resolve component names during elaboration
Modified the earlier AnnotationExample to show use of new annotation system, remove annotations from GCD example
Enhance dumpFirrtl to dump any annotations present, uses the firrtl file name as a template

Removed extraneous logic
Renamed doStuff to buildAnnotatedCircuit
Removed println's

Add AnnotationSpec file which provides an example of a way to implement generation of annotations in a chisel circuit that could be used by custom firrtl passes
This spec also shows and tests in a limited way the new API of .signalName, .pathName, parentModName which allows access to the various path information of a chisel component (something that subclasses SignalId, most prominently SubClasses of Data and Module

* signalName: returns the chirrtl name of the signal

* pathName: returns the full path name of the signal from the top module

* parentPathName: returns the full path of the signal's parent module instance from the top module

* parentModName: returns the signal's parent **module(not instance)** name.

* Make "def width" a private API; expose isWidthKnown instead

Resolves #256.

Since width was used to determine whether getWidth would succeed, I added

    def isWidthKnown: Boolean

but another option would be to expose something like

    def widthOption: Option[Int]

...thoughts?

* Document getWidth/isWidthKnown

* Add widthOption for more idiomatic Scala manipulation of widths

The API allowed this before, but not safely, as users could create
name conflicts.  This exposes the pre-deduplication/sanitization
naming API, and closes the other one.

It's not entirely clear what the FIRRTL implementation supports, so
I'm using the ANSI C requirements for the time being.

This has been deprecated for a long time now (and really shouldn't
have existed to begin with).

Deprecating toBits removes the capability to cast an arbitrary
type to UInt.  While it's still possible to do so using asBits.asUInt,
this creates boilerplate.  (asBits is almost never useful itself.)

For Chisel nodes defined in Module class-level values of type Option or
Iterable, we can still use reflection to assign names based on the name
of the value. This works for arbitrary nesting of Option and Iterable so
long as the innermost type is HasId. Note that this excludes Maps which
always have an innermost type of Tuple2[_,_].

Clean up Scala code, and use +& to generate a lot less FIRRTL

For reasonable circuit delay, need to divide & conquer.

Closes #229

h/t @sdtwigg @davidbiancolin

renamechisel3 - "chisel" -> "chisel3"

Rather than using a global counter, memoize the last returned value for
colliding names to generate smaller sequence numbers.

Rename package Chisel to chisel, add Chisel package for compatibility