Rename XSD/DTD generation code actions

[xorye]

@fbricon 's idea:

For these code actions:

Rename each of them to match this format:

Bind to the generated XSD 'test.xsd' with xsi:noschemaLocation to Generate 'test.xsd' and bind with xsi:noschemaLocation.

After, we could add another code action if test.xsd exists: Bind to 'test.xsd' with xsi:noschemaLocation.

[angelozerr]

+1

@xorye is there any chance that you work on this issue?

[xorye]

@angelozerr yes, I can look into this

[xorye]

For this issue:

• Rename code actions
• Add new code action for when the schema file already exists

[datho7561]

@angelozerr do you think the second portion of this issue is worth pursuing? I know we were thinking of implementing a command that will bind to a schema that is passed by the client. (ie. the client provides a wizard to select the schema file, then calls a LemMinX command to bind the document to the schema). However, using a CodeAction in this scenario means nothing needs to be implemented on the client side.

[angelozerr]

However, using a CodeAction in this scenario means nothing needs to be implemented on the client side.

The idea with CodeAction is to generate a CodeAction with a command id (only when client has the proper capability). This command id will used on client side to open a XSD files (This part could be managed by redhat-developer/vscode-xml#395 which will work with CodeLens).

In short I think we could split this issue in 2 isssues like explained #807 (comment)