(maint) Fix expect_upload for module relative paths outside files

[jpartlow]

The expect_upload() BoltSpec expectation for upload_file calls in plans handled two cases:

Given a /my/modules/amodule with

/my/modules/amodule/files/foo
/my/modules/amodule/resources/baz
/my/modules/amodule/plans/bar

expect_upload('/some/thing') would correctly match against an upload_file('/some/thing') in plan bar, because it is not relative to the modulepath at all, and against an upload_file('amodule/foo'), because it is relative to amodule, and foo is relative to files, which expect_upload elides when the MockExecutor runs the source_path through BotlSpec::MockExecutor#module_file_id.

The edge case that was peculiar was a call to
upload_file('amodule/files/../resources/baz'), which expect_upload would end up expecting as 'amodule/baz'.

The hidden behavior here is that Bolt::Util.find_file* functionality will take 'foo/bar' and look for /modulepath/foo/files/bar, which is mirroring Puppety behavior to find module files relative to the files/ dir.

[jpartlow]

I'll deal with my offenses to the linting gods; but I'm not entirely certain about this patch either way.

Even an expect_upload('amodule/resources/bar') is a bit odd, since you'd be inclined to think it was really 'amodule/files/resources/bar'. Not sure what the ideal behavior is here or if this is worth patching.

[jpartlow]

Would also need some fiddling to make the module_file_id tests OS agnostic, or drop them.