Ref and Lib paths need some platform pattern for 32 vs 64 bit Frameworks

[hopscc]

On Windows/ .Net
Ref and Lib paths are currently static and evaluated as in in cobra.
That means the platform bit-width is wired to the ref/lib entry.
Use on a different bit-width platform will fail with unfound path/files

These need some way of specifying the 'framework place' independent of whether platform is a 32 or 64 bit platform.
e.g paths:
'C:\Windows\Microsoft.NET\Framework\v4.0.30319\...'
vs
'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\...'

(at min some expansion pattern for 'Framework' vs 'Framework64').

Env var expansion is one possibility but then requires something else to set env var ( for platform type/bit width windows does not seem to do).

.Net platform knows bit-width ( Environment.Is64BitProcess) so suggest some pattern that cobra compiler expands in ref and lib Paths

e.g. '{Platform_Framework}'

above two become
'{Platform_Framework}\...'
(cf %APP_DATA% )

[hopscc]

Another (simpler) possibility would be to add an additional lookup path step if all existing lookups fail: append the given reference to the runtime framework path and see if the file exists to load
existing hardwired

use 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework'

fails on 64 bit system/framework.

If use pattern/ref was just

use 'WPF\PresentationFramework'

and final additional lookup looked in
{Platform_Framework}
i.e for path '{Platform_Framework}\PresentationFramework'
then it would be self correcting for the Framework in use without having to specify anything.....

[hopscc]

Refactor ref path lookup code,
add additional (end) case to look for assemblies in current Framework path.
Also add expansion patterns for full Framework Path and 'Framework_on_platform' portion of Path

'(_FWP}' # full FrameWorkPath
'{_FW}'  # Framework/Framework64

additional tests.

THis should work same way on mono ( for looking in full Framework path) and full framework path expansion and will expand patterns same way if mono has 'Framework' vs 'Framework64' in its framework install paths but is untested - mono may need additional or changed pattern expansions.
(tests are dotnet specific).