[Re-Build] Enhancement: Property Set file input field + general improvements

This PR adresses https://github.com/modxcms/revolution/issues/11238

With the proposed changes it is possible to define a property field as a file input to select a file from the media browser like it is known from file/image TVs. This PR has actually grown to a wider improvement of property sets drag and drop usage overall...

The main advantage (at least for me + my clients) is that many (slow) TVs can be completely avoided with this functionality...I can just train my clients to use the element tree and drop in the modules they need where they need them and configure them like they would have through TVs before...just more sexy =)

Before (Chunk -> Property Sets Edit View):
![bildschirmfoto 2014-06-19 um 20 41 19](https://cloud.githubusercontent.com/assets/445501/3332356/76992264-f7e6-11e3-973f-5ea16edb376d.png)

After (Chunk -> Property Sets Edit View):
![bildschirmfoto 2014-06-19 um 20 44 49](https://cloud.githubusercontent.com/assets/445501/3332360/8f79b8d4-f7e6-11e3-8694-9d99041fb733.png)

This is possible with the new combo-box entry "File" as can be seen here:
![bildschirmfoto 2014-06-19 um 20 44 35](https://cloud.githubusercontent.com/assets/445501/3332365/9d07c8a6-f7e6-11e3-867f-571ff1b9d5cd.png)

Behavior before changes:
![modx propertyset drop old](https://cloud.githubusercontent.com/assets/445501/3332372/b2cd28d4-f7e6-11e3-8ae0-99837adc95b5.gif)

Bahavior and demo with the proposed changes:
![modx propertyset drop new](https://cloud.githubusercontent.com/assets/445501/3339807/62936ada-f873-11e3-9c9a-9f4f98706953.gif)

This is tested with MODX 2.2.14pl advanced and MODX 2.3dev (git build from 19.6.2014), it works with different media sources as specified in the "default_media_source" system/context setting depending on the context the currently edited resource is in (to which the element is dropped). Also tested with multiple property sets and multiple file input fields (they need to have different names though, as the name is used for the tvbrowser field...)

I increased the width of the property set combo to be 300px as it cuts of already the default property set name in german for example. Additionally I added a little JS to auto load the property sets combo as it just shows a "0" when initially opened, this is not very helpful/informative and often confuses clients/editors, so now the real name, e.g. "Default", of the currently displayed property set. The autoloading on render somehow only works when setting the value to '0' afterwards (string, not int...), so I had to weaken the check if or not to add the @PropertySetName to the inserted MODX tag, as it checked strictly for value !== 0, no it's value != 0, which also takes '0' into account.

~~To make this thing work I had to add getValue() methods to the file TV render (also added it to image TV render, as it is basically the same). This method could also be convenient in other scenarios I think...~~ EDIT: Could solve it without the additional method, if this was a good improvement in general I can re-add it...

Added some further enhancements in general:
- Allow input of time for the date input field type
- Equalized widths of fields to blend better in the UI
- Make integer field work correctly, until now it's just a textfield, that also allows strings...
- Make @ bindings (known from TVs) to be parsed to generate list options

before:
![bildschirmfoto 2014-06-20 um 14 50 43](https://cloud.githubusercontent.com/assets/445501/3340160/94d1ad80-f879-11e3-96f6-abb504332e0e.png)

after:
![bildschirmfoto 2014-06-20 um 14 42 38](https://cloud.githubusercontent.com/assets/445501/3340140/5081686e-f879-11e3-9772-751c7637377a.png)


The powerful possibility to use @ bindings to generate list options for the list input field type is a further improvement of property sets. It works the same way as known from listbox TVs. To keep it "simple" / the code bloat as small as possible, I added this capability to the existing list input field type, instead of creating a new one. Like this it is possible to have even multiple @ binding calls to generate the list options + manually added ones all together. All that has to be done is to create a list option and enter an @ binding statement as the value, like:

```php
@EVAL return $modx->runSnippet('getListBoxItems');
```

The name for this Option doesn't matter, it will not be shown anywhere...this would look like this:
![bildschirmfoto 2014-06-21 um 15 24 47](https://cloud.githubusercontent.com/assets/445501/3348894/c8d484d0-f947-11e3-94d1-6f5a6a8e930b.png)

and resulting in:
![bildschirmfoto 2014-06-21 um 15 26 47](https://cloud.githubusercontent.com/assets/445501/3348896/d166d63e-f947-11e3-99c4-a4d7064d5047.png)

the code used for this demo snippet is rather simple, but could be anything from a resource list to whatever you can imagine =), as long as it comes back as a properly formatted input options stringe like "list item 1==1||list item 2==2||list item3==3":

```php
$count = 10;
$output = array();

for ($i=0;$i<=$count;$i++) {
    $output[] = 'Snippet generated List Item ' . $i . '==' . $i;
}

return implode('||', $output);
```

If this PR gets merged (hopefully as soon as for 2.3 =D), I'll document the added features in the RTFM