Function and instruction breakpoint log message

There is not really any reason for them to not support logMessage field. This was raised in #114, but that post includes different issues as well.

"FunctionBreakpoint": {
	"type": "object",
	"description": "Properties of a breakpoint passed to the `setFunctionBreakpoints` request.",
	"properties": {
		"name": {
			"type": "string",
			"description": "The name of the function."
		},
		"condition": {
			"type": "string",
			"description": "An expression for conditional breakpoints.\nIt is only honored by a debug adapter if the corresponding capability `supportsConditionalBreakpoints` is true."
		},
		"hitCondition": {
			"type": "string",
			"description": "An expression that controls how many hits of the breakpoint are ignored.\nThe debug adapter is expected to interpret the expression as needed.\nThe attribute is only honored by a debug adapter if the corresponding capability `supportsHitConditionalBreakpoints` is true."
		},
+		"logMessage": {
+			"type": "string",
+			"description": "If this attribute exists and is non-empty, the debug adapter must not 'break' (stop)\nbut log the message instead. Expressions within `{}` are interpolated.\nThe attribute is only honored by a debug adapter if the corresponding capability `supportsLogPoints` is true.\nIf either `hitCondition` or `condition` is specified, then the message should only be logged if those conditions are met."
+		}
	},
	"required": [ "name" ]
},

"InstructionBreakpoint": {
	"type": "object",
	"description": "Properties of a breakpoint passed to the `setInstructionBreakpoints` request",
	"properties": {
		"instructionReference": {
			"type": "string",
			"description": "The instruction reference of the breakpoint.\nThis should be a memory or instruction pointer reference from an `EvaluateResponse`, `Variable`, `StackFrame`, `GotoTarget`, or `Breakpoint`."
		},
		"offset": {
			"type": "integer",
			"description": "The offset from the instruction reference in bytes.\nThis can be negative."
		},
		"condition": {
			"type": "string",
			"description": "An expression for conditional breakpoints.\nIt is only honored by a debug adapter if the corresponding capability `supportsConditionalBreakpoints` is true."
		},
		"hitCondition": {
			"type": "string",
			"description": "An expression that controls how many hits of the breakpoint are ignored.\nThe debug adapter is expected to interpret the expression as needed.\nThe attribute is only honored by a debug adapter if the corresponding capability `supportsHitConditionalBreakpoints` is true."
		},
+		"logMessage": {
+			"type": "string",
+			"description": "If this attribute exists and is non-empty, the debug adapter must not 'break' (stop)\nbut log the message instead. Expressions within `{}` are interpolated.\nThe attribute is only honored by a debug adapter if the corresponding capability `supportsLogPoints` is true.\nIf either `hitCondition` or `condition` is specified, then the message should only be logged if those conditions are met."
+		},
		"mode": {
			"type": "string",
			"description": "The mode of this breakpoint. If defined, this must be one of the `breakpointModes` the debug adapter advertised in its `Capabilities`."
		}
	},
	"required": [ "instructionReference" ]
},

The issue identifies the FunctionBreakpoint and InstructionBreakpoint schema definitions; find those definitions in the protocol schema and compare their existing breakpoint properties. Add the proposed logMessage field to both, then verify that both schemas expose it consistently.