-w Mojo::Asset::File (again)...

An answer for #649 with revert of 04aa323e plus augmenting similar to [comment](https://github.com/kraih/mojo/pull/649#issuecomment-59644444) and as an alternative to interface change of #694, though not really feedback as such.

Whether all files that *can be* opened in append|write mode *should be* is the question to answer. Explicitly including a mode property on the object elevates no unexpected privileges. Having said that, the ```add_chunk``` method makes appending, when permissions allow, an expected ability of said object though.

For what it is worth all tests succeeded during ```make test``` on a read-only filesystem.
```
$ make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/*/*.t
t/mojo/asset.t ............................. ok
<snip>
All tests successful.
Files=85, Tests=9939, 52 wallclock secs ( 1.57 usr  0.23 sys + 31.76 cusr  3.09 csys = 36.65 CPU)
Result: PASS
$ ls
CONTRIBUTING.md  Changes  LICENSE  MANIFEST.SKIP  MYMETA.json  MYMETA.yml  Makefile  Makefile.PL  README.md  blib  examples  lib  pm_to_blib  script  t
$ touch test.ro
touch: cannot touch `test.ro': Read-only file system
```
Points I'll make here are:
* ```-w _``` uses the stat magic and pulls from the previous ```-f``` so overhead does not involve the filessystem again
* ```stat(_)``` uses the same magic, again no touching of the filesystem *yet*
* ```utime``` only gets called **if** the file is writeable
* if ```utime``` is called it attempts to set the access and modification times to the original and no changes are seen

@kraih your concerns on effect on Headers warrant a test - I'll get to it

@alexbyk your point about ```F_GETFL``` makes me question ```utime``` usage and effects on portability

Static files served are read only, right - I mean correct?