feat: SPA routing fallback support

[lifeart]

resolves: #425

broccoli server able to detect index.html files on path requests like

/foo -> /foo/index.html and return it.

But, If we use livereload and js-based app navigation, broccoli don't drill down to root index.html for requests like:

/foo/bar

-> current lookup:
foo/bar/index.html, 404

-> expected lookup:
/foo/bar/index.html, /foo/index.html, index.html, 404

[stefanpenner]

Path manipulation from inbound requests always gives me the heebeegeebeez do to the potential of path traversal security issues. I would prefer to avoid as much liability here as possible. Do we think the fallback index.html lookup is something sufficiently commonly used to justify?

Or would a fixed index.html such as https://github.com/ember-cli/ember-cli/blob/2d77f099c19f2b54328e7e961e0b23a31a638661/lib/tasks/server/middleware/history-support/index.js#L63 be sufficient.

I can be convinced by either approach, the former will just require substantially more testing and care.

[lifeart]

@stefanpenner we could skip index search if path contain . to prevent traversal security issues.

I seen cases where multiple static apps composed into one using nesting (and have to deal with it):

root_app
   /child-app
   /some-side-app
   /help-app

[stefanpenner]

Ya it’s not a bad feature at all.

[lifeart]

@stefanpenner added guard for . in path 99b5a32#diff-92fc8ac710621cc64e5b3683c8c56bf5aec7a209c2968a1818bab04b11551811R87 and improved tests