Quoted strings/here-strings issues

Adding to issue #143,

Both double-quote and single-quote here-strings fail to tolerate trailing space on the opening line. Users might only notice the @ not highlighted, because regular quoted string still fires, but if any further quotes are used in the here-string, they will cause highlighting issues.
Single-quoted strings fail to highlight, if immediately following a backtick'd single-quote. Example:
```
echo `''hello there'
```
This statement outputs 'hello there.
(a) This statement highlights incorrectly because the begin regex incorrectly requires a match of a single-quote to which is not preceded by single-quote. This is flawed because the previous single-quote could be backticked. In reality the check for a prior single-quote is unneeded.
(b) Likewise the end regex requires matching a single quote not followed by another single quote, but this requirement can be eliminated by using the TextMate applyEndPatternLast property, setting it to true.
(a) Double quoted strings do not exhibit a similar behavior because the begin regex already checked for a backtick before the double-quote that cannot be before the real double-quote. But that logic is flawed. The backtick may have been backtick'd. However, it works, because, the need to check for a preceding double-quote is unnecessary.
(b) The end match for double-quoted strings can benefit from the same property as the single-quoted string.
Both double-quote and single-quote here-strings fail to scope the begin and end tokens as punctuation.

NOTE: these are relatively minor issues overall.

applies issue PowerShell#167 part 1

Applies issue PowerShell#167 part 2a, simplify regex

applies issue PowerShell#167 part 2b, optimization

applies issue PowerShell#167 part 3a, simplify regex

applies issue PowerShell#167 part 3b, optimization

Just added item 4. These items could use to have tests added when they are fixed (1,2a and 4).

Would need to determine what that scope should be for item 4.

While I have commits for fixes/improvements, I'll hold off on a PR until given direction on combining #143, this issue (all 4 parts), and maybe #141. For instances, items 2 and 3 make #141 easier to implement. Do I combine them (but each committed separately) because they cover the same lines (or very close) or do I create PR's for each but incrementally creating each new branch from the previous one?

Thinking about it some more,

A PR for Double doublequotes in here-string scopes as a character.escape #143
A PR for this issue, but only part 1
A PR for Account for curly quotes in syntax definition. #141, which will inherently deal with this issue's part 2 and 3 (EDIT: but will require the PR for Account for curly quotes in syntax definition. #141 and this issue)

~~Each one will affect different lines.~~ EDIT: #141 would require changing the same lines as both #143 and this issue, part 1.
Each one could use tests added. A test for this issue's part 2a/3a would be included with the PR for #141.

Maybe its best in the end to just put them all in one PR?

applies issue PowerShell#167 part 1

Applies issue PowerShell#167 part 2a, simplify regex

applies issue PowerShell#167 part 2b, optimization

applies issue PowerShell#167 part 3a, simplify regex

applies issue PowerShell#167 part 3b, optimization

applies issue PowerShell#167 part 4,

applies issue PowerShell#167 part 1

tests for PowerShell#143 and PowerShell#167 part 1

fixes PowerShell#141, adds support curly quotes

applies issue PowerShell#167 part 4,