Rename Schema.md to Model.md and more docs on models

[shimks]

Renamed Schema.md to Model.md and added blurb on what a model should look like

• first commit contains the actual edits to the docs, so please review that one to make comparing diffs easier for yourself

• second commit is the renaming of the files

• Updating Thinking in Loopback and using JSON Schema have been covered by this PR: json-schema metadata #592

• connected to docs: Model loopback-next#555

[bschrammIBM]

I suggest a few edits as shown in the comments of the issue.

[bschrammIBM]

1. pages/en/lb4/Best-practices-with-Loopback-4.md line 19 This section shows how the endpoints can be physically tested ~~via~~ using the Swagger UI.
2. pages/en/lb4/Model.md lines 30-34 With extensibility being a core feature, there are packages that add quality of life features like integration with the legacy juggler and JSON Schema generation. These features become available to a LoopBack model through the ~~usage of~~ `@model` and `@property` decorators from the `@loopback/repository` module.

I suggest: Extensibility is a core feature of LoopBack. There are external packages that add additional features, for example, integration with the legacy juggler or JSON Schema generation. These features become available to a LoopBack model through the ~~usage of~~ `@model` and `@property` decorators from the `@loopback/repository` module.

3. lines 48-50 Defining a model for use with the legacy juggler involves extending your classes +from `Entity` and decorating your classes with the `@model` and `@property` +decorators.

I suggest: To define a model for use with the legacy juggler, you extend your classes from `Entity` and decorate them with the `@model` and `@property` decorators.

4. lines 76-78 The model decorator can be used without any additional parameters, or can ~~take~~ be passed in a ModelDefinitionSyntax object which follows the general format provided in LoopBack 3:

I suggest:
include link to LoopBack3 docs that provide definition of ModelDefinitionSyntax. include link to https://loopback.io/doc/en/lb3/Model-definition-JSON-file.html
5.lines 141-151 ~~Unfortunately,~~ There is a limitation to the metadata that can be automatically +inferred by LoopBack, due to the nature of arrays in JavaScript. In JavaScript, arrays do not possess any information about +the types of their members. By traversing an array, you can inspect the +members of an array to determine if they are of a primitive type +(string, number, array, boolean), object or function, but this would not tell us +anything about what the value would be if it were an object or function. ~~and +would require traversal of the array.~~ + +For consistency, we ~~have chosen to~~ require the use of the `@property.array` +decorator, which ~~will~~ adds the appropriate metadata for type inference of +your array properties.

6. lines 230-234 +If a custom type is specified for a decorated property in a model definition, then +a reference [`$ref`](http://json-schema.org/latest/json-schema-core.html#rfc.section.8) +field is created for it and a `definitions` sub-schema is created at the top-level +of the schema. ~~and~~ The `definitions` sub-schema is populated with the type definition by recursively calling +`getJsonSchema` to build its properties.