WIP: GoDaddy Contributions

Corrected generateModelDefinition() to scan for model references in remote accepts, returns, errors, and nested models
Changed addRoute() to honor X-Forwarded-Host
UI/UX cleanup for SwaggerUI
	Add support for toggling Model and Schema, instead of just expanding
	Added guard against null mockSignature
	Added support for toggling Model and Schema, and added support for primitives in StatusCodeView
	Changed to hide the message-bar when no message
	Changed to use defaultValue, if present, for sampleValue
	Changed to use relative path for images/throbber.gif for mounting into apps at different levels
	Collapse and label responseModel description by default
	Correct description of collections of object and nested
	Corrected to avoid showing invalid Model and Model Schema is missing or void
	Corrected to load images relative to swaggerRoot, for nested context root
	Corrected to work when loading resources from file://
	Ensure Response Content Type is shown regardless of Response Class
	Omit divs for info.title and info.description if they're absent
	Removed 'Implementation Notes' label since it's just noise, widened Resource expansion anchor to full label
@STRML @raymondfeng I need your help here as my knowledge of Swagger is not good enough.

Metadata like `type`, `format` and `items` is filled by `routeHelper.extendWithType`. Should we allow the developer to override this information? Or should we treat the values provided by the developer as a default and override them in `extendWithType`?

How about the new metadata - `$ref`? According to the spec, this is somewhat opposite of `type`, i.e. only one of them should be used.

The following metadata is not inferred from the type (yet) and thus it's IMO ok to customise them: `pattern`, `enum`, and `uniqueItems`. It would be better to support them directly in LDL and strong-remoting, but that's out of scope of this PR.

However, it leads me to the conclusion, that values specified in remoting metadata should be treated as a default and they should be overridden by `extendWithType`. That way when we add support in LDL, the swagger spec generated by loopback-explorer will describe the real constraints as seen by loopback.

I have no idea how to treat `allowMultiple`. Here is the spec:
> Another way to allow multiple values for a "query" parameter. If used, the query parameter may accept comma-separated values. The field may be used only if paramType is "query", "header" or "path".

It seems to me that this flag depends very much on what strong-remoting is willing to accept and process. If we support comma-separated values and parse them into an array, then this should be always true for relevant param types. If we don't support it, then this should be always false. Unless I am interpreting this in a completely wrong way.

Thoughts?